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PREFACE 


This manual helps you use the software tools provided by DIGITAL to 
program and use the KXT11-C Peripheral Processor. Detailed 
information about KXT11-C hardware and supporting software is provided 
by reference manuals which are cited throughout this manual. 


Reader Assumptions 


This manual helps the programmer using MicroPower/Pascal or one of the 
KXT11-C peripheral processor tool kits. It is possible to program and 
use KXT11-C's with traditional LSI-11 software development tools; 
however, guidelines for doing this are not discussed at any length in 
this manual. 


This manual assumes you are familiar with DIGITAL's LSI-11 series of 
computer products and have programming experience in one of the 
following environments: 


@e MicroPower/Pascal-RT-11, -RSX or -VMS host application 
development environment, writing programs in the 
MicroPower/Pascal or the MACRO-11 language. 


e RT-11, RSX-11M or RSX-1LIM-PLUS host system environment, 
writing and debugging MACRO-11 assembly programs for 
stand-alone PDP-11 applications. 


Document Structure 
This manual contains four chapters and six appendixes. 


e Chapter 1 summarizes the features of the KXT11-C hardware and 
its supporting software and provides examples of typical 
applications. 


e Chapter 2 describes the procedures for programming KXT11-C 
application systems. 


@e Chapter 3 provides information about programming a KXT11-C 
with MicroPower/Pascal software and using KXT11-C peripheral 
processors in MicroPower/Pascal arbiter applications. 


@ Chapter 4 describes how to use KXT11-C peripheral processors 
in applications based on RT-11 or RSX-11 system environments. 


@e Appendix A describes the communication protocol that the KX 
and KK device handlers use to pass messages between the 
arbiter processor and KXT11-C peripheral processors. It 
assists those who want to write their own KK or KX handler. 
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e Appendix B lists the CSR and interrupt vector assignments for 
KXT11-C devices. 


e Appendix C lists the CSR and interrupt vector assignments, KX 
device handler logical unit numbers, and system ID switch 
settings for the KXT11-C two-port RAM, 


e Appendix D shows a sample KXT11-C MicroPower/Pascal 
configuration file. . 


@e Appendix E describes the procedures for calculating checksums 
for PROMS that are loaded by the DECprom program. 


e Appendix F describes how your application can check for 
nonfatal error conditions reported by the native firmware's 
self-test routines. 


Associated Documents 


The following software and hardware documentation supports kKxXT11-C 
application development for host and target environments. The 
documents you will need depend on which host development system you 
are uSing and whether you are developing KXT11-C applications in the 
MicroPower/Pascal environment or in a . traditional MACRO-11 
environment. 


MicroPower/Pascal Application Development Environment 


The MicroPower/Pascal-RT documentation set, QJ929-GZ, provides a 
complete description of MicroPower/Pascal software tools in the 
RT-11 host system environment. 


The MicroPower/Pascal-VMS documentation set, QD#29-GZ, provides a 
complete description of MicroPower/Pascal software tools in the 
VAX/VMS host system environment. 


+ 


The MicroPower/Pascal-RSX documentation set, QP929-GZ, provides a 
complete description of MicroPower/Pascal software tools in the 
RSX-11M and RSX-11M-PLUS host system environments. 


Tool Kit Application Development Environment (for arbiter 
application development) 


KXT11-C Software Toolkit/RT Reference Manual, AA-AU63A-TC 


CR ES TS 


PROM Loading Utility Programs 

PB-11 System User's Guide, AA-848B-TC 

VAX/VMS DECprom User's Guide, AA-W754A-TK 

Host Operating System Documentation 

The MicroPower/Pascal documentation sets include documents’ from 


the sets listed below that are necessary to facilitate 
MicroPower/Pascal application development. 
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The RT-11 documentation set, QJ913-GZ, provides a complete 
description of the software tools for the RT-11 host environment. 


The RSX-11M documentation set, QJ628-GZ, provides a complete 
description of the software tools for the RSX-11M host 
environment. 


The RSX-11M-PLUS documentation set, QR5@9-GZ, provides a complete 
description of the software tools for the RSX-11M-PLUS host 
environment. 


The VAX/VMS documentation set provides a complete desertprion of 
the software tools for the VAX/VMS host environment. 


You will also need the following hardware reference documentation to 
configure your application hardware to use the standard device 
handlers, or to write device handlers that are hardware- and 
software-compatible with other system components: 


Microcomputer Manual 

KXT11-CA User's Guide hardware reference manual, EK-KXTCA-UG 
Microcomputer Handbooks 

MICRO/PDP~11 Handbook, EB-24944-18 

Microcomputers and Memories, EB-29912-26 

Microcomputer Interfaces Handbook, EB-2 3144-18 


PDP-11 Architecture Handbook, EB-23657-18 


Document Conventions 


1. Throughout the text, the term RSX-11 is used to simplify 
references that apply to both the RSX-11M and RSX-11M-PLUS 
operating systems. 


2. Pascal-reserved words that must not be abbreviated are shown 
in uppercase characters in syntax examples. Within those 
examples, lowercase characters are used for parameters or 
other Syntax elements that you must include for your 
particular application. 


3. All hardware device register and memory addresses specified 
in this manual are octal values (for example, 77xxxx). 
Addresses for the arbiter's Q-BUS memory are Shown as 22-bit 
values; while those for the KXT11-C are shown as 16-bit 


values. 

4. All command strings terminate with a carriage return. The 
symbol used in this manual to represent a carriage return is 
<RET>. 
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To produce certain characters in system commands, you must 
type a combination of keys concurrently. For example, while 
holding down the CTRL key, type C to produce the CTRL/C 
character. Key combinations such as this are documented as 
<CTRL/C>, <CTRL/O>, and so forth. 


In examples, you must distinguish between the capital letter 
O and the number 9. Examples in this manual represent these 
characters as follows: 


Letter O: e) 
Number 9: g 
The sample terminal output in this manual contains version 
numbers where they would normally appear. The version 


numbers include xx in those fields that can vary from 
installation to installation. 


CHAPTER 1 


INTRODUCTION 


The KXT11-C Peripheral Processor is. an LSI-11 single-board 16-bit 
computer with local memory and communication ports. You can use it as 
a self-contained stand-alone system or aS a component (peripheral 
processor) of an LSI-1ll-based multiple processor system. 


In a multiple processor system, you can add up to 14 user-programmed 
KXT11-C Peripheral Processors to traditional LSI-11 Q-BUS systems and 
communicate with them from the LSI-l1 CPU acting as arbiter. The 
software architecture is master/slave (not to be confused with the 
bus-master/bus-slave hardware concept) which means the KXT11-C 
application (slave) performs operations only on command from the 
arbiter application (master). The master application runs in the 
LSI-11 (Q-BUS) arbiter processor and controls the KXT11-C application 
by sending it messages over the KXT11-C two-port RAM (TPR) registers 
in the I/O page. The KXT11-C can also transfer data to and from main 
memory with its DMA transfer controller facility (DTC). 


When configured for stand-alone operation, the KXT11-C is completely 
self-contained with no Q-BUS required. 


The DIGITAL-supplied software supports KXT11-C single-board computers 
as stand-alone systems or as peripheral processors in a multiple 
processor environment. You can program the kKXT11-C using the 
MicroPower/Pascal or MACRO-11 language. In peripheral processing 
applications, you can then incorporate the processors into arbiter 
applications based on the RT-l1l, RSX-11M, RSX-LIM-PLUS or 
MicroPower/Pascal operating environment. 


In addition to DIGITAL's standard LSI-1l software development tools, 
you can choose from the following three software products that provide 
tools for KXT11-C application development: 

@® MicroPower/Pascal 


@ KXT11-C/RT-11 Peripheral Processor Tool Kit 


@e KXT11-C/RSX-11 Peripheral Processor Tool Kit 
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MicroPower/Pascal software provides tools for developing KxT11-C 
stand-alone or peripheral processor applications in MicroPower/Pascal 
and MACRO-11 under the control of the MicroPower/Pascal run-time 
kernel. Included are handlers for the following KXT11-C on-board 
devices: 


Asynchronous serial I/0 
Synchronous serial I/0 
Parallel I/O and counter-timers 
Real-time clock 

DMA transfer 


For peripheral processor applications, device handlers provide 
communication through the two-port RAM (TPR). They allow a 
MicroPower/Pascal application on the KXT11-C to communicate with a 
MicroPower/Pascal, RT-11, or RSX-11 application in the arbiter 
processor. MicroPower/Pascal provides a device handler for 
MicroPower/Pascal arbiter applications. The handlers for RT-11 and 
RSX-11l are available in the tool kits. 


The KXT11-C peripheral processor tool kits provide tools for using 
peripheral processors in traditional Q-BUS systems. Support is 
provided for RT-1ll, RSX-11M, and RSX-11M-PLUS arbiter applications to 
load and communicate with KXT11-C peripheral processors across the 
Q-BUS. The handlers communicate with KXT11-C processors programmed in 
MicroPower/Pascal. 


If those tools do not meet your needs, you can program the KXT11-C in 
the MACRO-11 assembly language using the standard PDP-11 application 
development tools (MACRO-11, LINK, ODT, MACDBG, and so on). 


If your KXT11-C application program uses ROM, you can load it with the 
DECprom program (VMS systems) or the PROM/RT-11 program (RT-11 
systems). 


1.1 KXT11-C HARDWARE FEATURES 


Figure 1-1 shows the general layout of the following major hardware 
components. DIGITAL-supplied software supports most but not all 
hardware features; the software documentation describes the features 
supported. 
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Figure 1-1: KXT11-C Hardware Features 
e DIGITAL DCT-11 microprocessor -- A 16-bit, 7-MHz 
microprocessor that executes the PDP-11 basic instruction set. 
e On-board memory -- Local memory consisting of 32K bytes of 
static read/write memory (RAM), sockets for up to 32K bytes of 
PROM or static RAM, and 8K bytes of native firmware. 
Additional features include eight memory map configurations, 
and battery backup for native RAM. 
e Native firmware -- Provides: 
Power-up self test 
Optional loopback tests 


Hardware initialization 


Serial ODT accessible from a console terminal or via the 
QO-BUS 


Application start-up: ROM, TU58 boot, or load from the 
Q-BUS arbiter 


@ Two-port RAM (TPR) -- A 16-word interface to the Q-BUS that 
passes control information and data between the KXT11-C and 
the arbiter. The RAM is divided into three areas: one area 


for KXT1l1-C native firmware commands and two areas. for 
application message passing. 
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@ Two-channel DMA transfer controller (DTC) -- A device that 
provides for memory and I/O data transfers between the local 
KXT11-C and global memory on the Q-BUS using direct memory 
access. Permitted transfer combinations are: 


Local memory to global memory 
Global memory to local memory 
. Local memory to local memory 
Global memory to global memory 
® Parallel I/O interface -- Contains two bidirectional 8-bit 
input/output ports, one 4-bit control port, and three 16-bit 


programmable counter-timers. 


e Console port (DLART) -- Provides DLll-compatible asynchronous 
serial communication. 


® Multiprotocol controller -- Provides two-channel 
synchronous/asynchronous serial I/O communication 


e System ID switch -- Sets the system identification address and 
establishes the KXT11-C for Q-BUS or stand-alone operation. 


e Boot/Self-test switch -- Selects bootstrap and firmware 
self-test operations. 


e Configuration jumpers -- Electrical jumpers on the KXT11-C 
circuit board that select some of the hardware configuration 
options (other options are software configurable). 


Refer to the KXT1I1-CA User's Guide hardware reference manual for 
detailed information about the KXT11-C hardware. 





1.2 USING THE KXT11-C AS A PERIPHERAL PROCESSOR 


Peripheral processor applications help you off-load tasks from a 
conventional LSI-l1l processor application. This improves overall 
system performance by distributing the application task load. You can 
add up to 14 KxXT11-C peripheral processors to a traditional LSI-11 
(Q-BUS) system configuration in the same way you add other I/O device 
controllers (Figure 1-2). The difference between the KXT11-C and 
conventional I/O devices is that the kKxT1l1-C is user programmable 
while conventional I/O devices are not. 
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Figure 1-2: Adding KXT11-C Peripheral Processors’ to Traditional 
LSI-11 Systems . 


The following are examples of tasks that KXT11-C peripheral processors 
can perform. 


@e Guaranteed response time -- A dedicated KXT11-C can assure a 
specific interrupt response time. 


@ Data collection and reduction -- The arbiter is relieved of 
the overhead of the interrupts required to control devices and 
the CPU Q-BUS time required to refine and format the data. 


@ Machine control -- The arbiter processor gives high-level 
commands to the KXT11-C. The KXT11-C translates the commands 
to the level required by the device(s) and monitors progress. 
The arbiter application merely issues commands and manages 
higher-level application tasks. 


e Communication protocol handling -- The KXT11-C relieves the 
arbiter processor from handling communication line interrupts, 
packing/unpacking messages, and formatting them. Only data is 
transferred to and from the arbiter. 
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1.2.1 Peripheral Processor Hardware Configuration 


The application system consists of one Q-BUS arbiter CPU (LSI-11, 
LSI-11/2, SBC-11/21, LSI-11/23, LSI-11/23-PLUS or LSI-11/73) and up to 
14 KXT11-C peripheral PEOCeSEOLS attached to the Q-BUS. The KXT11-C 
cannot be a bus arbiter. 


Communication between the arbiter and the peripheral processor takes 
Place over the Q-BUS through the TPR. The TPR's control, status and 
data registers, and vectors appear in the arbiter's I/0 page. 
Programs can access the registers in ways similar to those of I/0 
devices. The peripheral processor's hardware configuration options 
determine where its TPR area appears in the arbiter's I/O page. 


1.2.2 Peripheral Processor Application Software Configuration 


A master application in the arbiter processor directs slave peripheral 
processor operations (Figure 1-3). Communication takes place over the 
Q-BUS using messages to control the kKXT11-C hardware and its 
application software and to transfer data. Communication can take 
place using the TPR or the DMA transfer controller (DTC). If desired, 
the peripheral processor can interrupt the arbiter application when it 
completes the requested task. 









commands and messages 


DMA data transfers 





















ap ! kk. 
handler | handler. 


peripheral 
processor 
application 


ap |! kk 
handler | handler 
= peripheral _ 
processor 
application 


KX | 
handler | 



















arbiter application 


LSI-11 PROCESSOR 


Figure 1-3: Peripheral Processor Application Software Configuration 
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1.2.3 KXT11-C Application Development Software Tools 


DIGITAL provides the following software tools to support development 
of KXT11-C applications for peripheral processing and stand-alone 
environments. 


Tools for Developing KXT11-C Peripheral Processing or Stand-alone 
Applications 


@® MicroPower/Pascal 


e Traditional development tools: MACRO-11, TKB/LINK, MACDBG, 
ODT 


@ VAX DECprom or RT-11 PROM/RT-11 for loading PROMS 
Tools for Developing Arbiter Applications Using the KxT11-C 
@ MicroPower/Pascal 


@e KXT11-C peripheral processor tool kits for RT-11 and RSX-11 
and the traditional development tools: MACRO-1l1, TKB/LINK, 
MACDBG, ODT 


1.2.3.1 MicroPower/Pascal - MicroPower/Pascal supports development 
and use of KXT11-C applications in the environments listed above. You 
can write application programs in MicroPower/Pascal or MACRO-11 and 
place the target application in RAM or _ ROM. MicroPower/Pascal 
software provides a complete set of tools for building, debugging, and 
loading peripheral processor applications. It includes a modular 
kernel that provides 43 primitive services, system initialization, 
event/priority scheduling, and interrupt and exception dispatching. 
Device handlers provide support for all on-board devices and _ for 
communication between the arbiter and one or more KXT11-C peripheral 
processors. The KXT_LOAD procedure loads KXT1L1-C peripheral 
processors from memory image files residing in the arbiter's mass 
storage. 


MicroPower/Pascal provides the following tools for the KXT11-C. 


@e DD handler (TU58 DECtape II) -- The DD device handler supports 
logical and physical I/O operations on a TU58 cartridge tape 
subsystem. The TU58 subsystem can be interfaced through any 
or all of the three serial I/O ports on the KXT11-C. Each 
subsystem can have two drives. 


® XL handler (asynchronous serial line) -- The XL handler 
supports concurrent operation of all three serial I/O ports in 
asynchronous mode with full modem control for one of the 
ports. 


e XS handler (synchronous serial line) -- The XS device handler 
supports channel A of the synchronous/asynchronous controller 
(MPCC) serial I/O ports in synchronous mode using bit-oriented 
block mode transfers. 
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YK handler (parallel I/O) -- The YK device handler supports 
the 28 bits of the parallel I/O port and three counter-timers. 
It supports most combinations of 4-bit, 8-bit, or 16-bit port 
configurations and the interlocked, strobed, pulsed, and 
three-wire handshake modes. Ports can be input, output, 
bidirectional, or mixed mode. The YK handler also supports 
DMA data transfers (using one of the DTC channels) to and from 
the port, the three independent 16-bit counter-timers, and the 
pattern matching feature. 


QD handler (DMA transfer controller) -- The QD device handler 
supports DMA data transfer operations using the DMA transfer 
controller (DTC). The handler provides two high-speed 
channels for a MicroPower/Pascal application to transfer data 
between global Q-BUS memory and local memory on the XKxXT11-C. 
It can also perform transfers completely within the KXT11-C 
memory or the Q-BUS memory. 


KK and KX handlers (arbiter-to-KXT11-C Q-BUS interface) -- The 
KK and KX handlers aid in programming the Q-BUS communication 
interface between the KXT11-C and the arbiter application. 
The handlers use the two-port RAM (TPR) to pass 
variable-length messages between applications. 


When using these handlers, the KXT11-C functions as a_ typical 
Q-BUS device in a master-slave relationship with the Q-BUS 
arbiter. The arbiter (master) controls all interactions 
between the two processors. The KXT11-C (slave) waits for a 
command from the arbiter processor before initiating a message 
transfer. The handlers use a request-reply protocol to assure 
that message transfers are complete and correct. 


Appendix A describes the KK/KX communication protocol to 
assist those who want to write their own KK or KX handler. 


Device handler support routines -- A group of 
MicroPower/Pascal functions that provide a Pascal interface to 
the KXT11-C device handlers. 
Kernel features specified using the KXT1IC macro: 


BHALT parameter to enable/disable debugging traps in 
response to the arbiter's BHALT signal. 


POWER parameter to determine the action to take on power 
failure and restoration. 


CLOCK parameter to enable/disable the KXT11-C's real-time 
clock at system start-up. 


RESET parameter to determine the action to take in 
response to the arbiter's BRESET signal. 


MAP parameter to identify the memory map used on_ the 
KXT11-C. 
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e KXT LOAD peripheral processor load procedure -- KXT_LOAD is a 
MicroPower/Pascal utility procedure for ldading one or more 
KXT11-C peripheral processors. The procedure readS a memory 
image file (.MIM file type) from a specified mass storage 
device and loads the memory of a designated KXT11-C over the 
Q-BUS. KXT LOAD is described in Appendix H of the 
MicroPower/Pascal Runtime Services Manual. 


1.2.3.2 KXT11-C Peripheral Processor Tool Kits - The KXT11-C 
peripheral processor tool kits are for RT-11, RSX-11M and RSX-11M-PLUS 
arbiters. They provide the software for the arbiter application to 
load and communicate with user-programmed KXT11-Cs. The tool kits 
contain the following software: 


e KX device handler (Q-BUS interface) -- The KX handler is’ the 
device handler/driver for LSI-11 (Q-BUS) systems. It allows 
the arbiter application to communicate with the KK handler 
running under MicroPower/Pascal in the KXT11-C. See Appendix 
A for a description of the KK/KX communication protocol. 


e KUI load utility -- The KUI program loads memory image files 
into a KXT11-C over the Q-BUS. It accepts the RSX-11 .MIM and 
-TSK file types and the RT-11 .MIM, .SAV and .LDA file types. 


1.2.3.3 Traditional PDP-11 Application Development Software Tools - 
You can also program the KXT11-C in MACRO-11 using the traditional 
PDP-1l assembly language tools provided with RT-11 and RSX-11 systems. 
These tools’ include: MACRO-11, TKB (RSX-11 task builder) or LINK 
(RT-11 linker), and ODT. In addition, RT-11 supports the MACDBG 
remote symbolic debugger which operates on an RT-11 host connected by 
serial line to the target KXT11-C. Refer to the appropriate software 
product description (SPD) for complete information. 


1.2.3.4 DECprom and PROM/RT-11 Utility Programs for PROM Loading - 
The VMS DECprom utility and the PB-11 system's PROM/RT-11 utility load 
EPROMS and PROMS. DECprom accepts input files of the .MIM, .SAV, 
-LDA, .EXE and .TSK types. It can generate ROM checksums in the 
format used by the ROM verification self-test routines in the native 
firmware. PROM/RT-~11 accepts input files of the .MIM .LDA and .SAV 
types. 


1.3 USING THE KXT11-C AS A STAND-ALONE SYSTEM 


The KXT11-C also satisfies applications where a single-board computer 
is required. When used as a stand-alone system, the KXT11-C operates 
independently from the Q-BUS (though it can receive power from 
Q-BUS-wired backplanes). All the peripheral processing tools 
described in Section 1.2.3.1 are applicable to stand-alone application 
development except for the KK and KX device handlers. 


CHAPTER 2 


KXT11-C APPLICATION SYSTEM DEVELOPMENT CYCLES 


This chapter summarizes the following procedures and decisions you 
must make when developing a KXT11-C peripheral processing application 
system or a KXT11-C stand-alone application. 


@e Decide which application processes the KXT11-C will perform. 


e Decide how to match process requirements with the KXT11-C's 
functionality and performance. 


@e Decide which software tools you will use for KxT1l1-C and 
arbiter application development. 


e Program and test each component of the application system. 


e Combine and test the application system (arbiter and all 
KXT11-Cs) 


The following sections provide a general description of these 
procedures and decisions. Succeeding chapters will help you 
understand how to most effectively use the software development tools 
in the application development process. 


2.1 PERIPHERAL PROCESSOR APPLICATION DEVELOPMENT CYCLE 


The following subsections describe the procedures to follow when 
developing a peripheral processor application and the specific 
considerations for such applications. 


2.1.1 Partitioning the KXT11-C Application 


Determine if your application can be partitioned to take advantage of 
multiple processors. There must be a set of processes that can be 
performed usefully in parallel and within the capabilities of the 
KXT11-C hardware. It must be possible to direct and monitor the 
progress of the process through messages or transfer of blocks of 
data. Some characteristics of processes that are good candidates for 
KXT11-C applications: 


e Input/Output processes with critical interrupt latency 
requirements -- By assigning processes with critical interrupt 
latency requirements to dedicated KXT11-C peripheral 
processors, you can assure that the rest of the application 
does not interfere with the service of critical devices. 
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e Input/Output processes with a high frequency of interrupts -- 
KXT11-C peripheral processors can relieve the arbiter from the 
continual context switching required to process 
interrupt-driven I/O. 


@e Input/Output data reduction processes -- By assigning one or 
more KXT11-C peripheral processors to I/0 processes that 
require large quantities of input data and produce ae_e small 
amount of output, you can save arbiter processing time. The 
peripheral processor receives the data, decodes it and reduces 
it to the required subset, discarding the rest. 


e Computational processes -- The KXT11-C can perform parallel 
computational operations by using the DMA transfer controller 
(DTC) to transfer data directly to its memory, perform the 
operation, and transfer the data back to Q-BUS memory. 


e Real-time control functions -~ You can assign a KXT11-C to 
control functions that require constant interaction with a 
device but little interaction with the main application. The 
arbiter can then direct the peripheral processor with 
high-level commands. 


2.1.2 Choosing the Application Software Development Tools 


Decide which of the available software tools best suits your 
application. You can choose from the following system application 
development environments. 


@ MicroPower/Pascal 
e RT-11 

@e RSX-11M 

@ RSX-11M-PLUS 


Each of these arbiter application environments contains a device 
handler/driver that communicates with a device handler in one or more 
KXT11-C applications, and a utility to load the KXT11-C with 
application software. With MicroPower/Pascal, you can write your 
KXT11-C application programs in Pascal or MACRO-11. With RT-11 and 
RSX-1l you can write your own system and application software in 
MACRO-11. 


MicroPower/Pascal provides you with modular system building blocks, 
important functions such as semaphores, queues and ring buffers, a 
choice of Pascal or MACRO-11 languages, and a complete set of 
application building, loading and symbolic debugging facilities. 


If you choose MicroPower/Pascal, be sure that its device handlers 

support the hardware features you need. The handlers support most but © 
not all features of the hardware. Refer to the MicroPower/Pascal 
System User's Guide and the MicroPower/Pascal Runtime Services Manual 
for detailed information on the MicroPower/Pascal device handlers. If 
you decide to modify a MicroPower/Pascal device handler, you can 
obtain its source file from DIGITAL as part of a separate source kit. 
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Your arbiter application design decision depends on what you need from 
an operating system. RT-11 and RSX-11 are general-purpose, real-time 
oriented operating systems, single user and multiuser respectively. 
The other choice, MicroPower/Pascal, is for dedicated application 
systems. You can find more information about these systems in 
succeeding chapters and in the documentation listed in the Preface. 


2.1.3 Designing the KXT11-C Application System 


In a KXT11-C peripheral processor application, you must design the 
communication protocol between the arbiter application and _ the 
KXT11-C. This is an application-level protocol for controlling and 
passing data between the KXT11-C application processes and the 
arbiter. Think of the KXT11-C application as an intelligent I/0 
device used by the arbiter. You design the protocol to command the 
device to perform its functions (for example, start, stop, and 
transfer data). The commands are generally formatted into messages 
and sent through the two-port RAM (TPR). 


MicroPower/Pascal provides the KK/KX device handler pair to facilitate 
TPR communication in applications using MicroPower/Pascal for the 
KXT11-C and arbiter. RT-11l and RSX-11 versions of the KX device 
handler are also provided in the KXT11-C peripheral processor tool 
kits to allow a KXT11-C using the MicroPower/Pascal KK device handler 
to communicate with an RT-11 or RSX-11 arbiter application. 


In addition to commands, you can also use the TPR to send data as 
messages, depending on the amount and frequency of occurrence, or you 
can transfer it directly using the DMA transfer controller (DTC). 
When you use the DTC, the arbiter typically passes a message to the 
peripheral processor specifying the location of the data buffer to 
transfer. The KXT11-C application then directs the DTC locally to 
make the transfer. 


In general, you should use the TPR to send small messages or 
infrequently issued messages. You should use the DTC to send large 
messages or frequently issued messages, especially if this can be done 
in parallel with other KXT1I1-C processes. When to use the DTC depends 
on the applications and must be determined on a case-by-case basis. 


When using the TPR to send large but infrequent messages, if your 
application makes no other use of the DTC, you need not build its 
handler into your application, thereby saving memory space. 


2.1.4 Coding the KXT11-C Application 


Code and test each application process in stages that minimize the 
number of new variables at each stage. The exact procedure will be 
application-dependent, but here are some suggestions. 


e Develop the KXT11-C application and arbiter application 
separately in a stand-alone environment. 


e Isolate communication between the arbiter and KXT11-C to one 
process or process group on each side. Create separate test 
processes to validate and exercise communication linkages on 
each side. 
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e Separately test and debug all application processes before 
integrating them in the peripheral processing environment. 


e Remove the test processes and integrate the communication 
processes only when you are confident that the arbiter and 
KXT11-C applications are operating correctly. This avoids the 
need for loading two or more targets for testing until the 
bulk of the application system has been debugged. 


2.1.5 Developing Test Processes 


The test processes you create should exercise and validate the 
functions of the arbiter and KXT11-C applications. Each process 
should simulate the operation of the other peripheral processing 
system component. For example, the test process on the arbiter should 
simulate the operation of the KXT11-C application. An 
atbiter-resident test process is useful for performing regression 
tests on the KXT11-C, because the actual KXT11-C application should. 
produce the same results as those simulated by the test process. 


2.1.6 Building an Application Debugging Configuration 


The application configuration for debugging is slightly different from 
the final configuration. If you are using the PASDBG or MACDBG remote 
debugger you must build a debugger service module (DSM) into your 
application. If you are using MicroPower/Pascal you must enable the 
debugging option in the compiler and include debugging symbols in the 
MERGE, RELOC, and MIB build steps. 


If you are developing a ROM application you must decide how to test 
Le. ROM applications are usually debugged using RAM or a ROM 
emulator. 


Next you must decide how you are going to load the application image 
into the target. Your options for loading the application for 
debugging are: 


e Load using a remote debugger. 

e Boot target system from TU58 DECtape II media. 

e Load from arbiter's mass storage with the KUI load utility. 

e Load from arbiter's mass storage with the KXT_LOAD procedure. 


You cannot use the last three options with remote debuggers; thus, 
they are of less utility than the first option in the debugging stage 
of development. In general, you should use a debugger to load your 
application unless your application needs the memory occupied by the 
debugger service module. In this case, you will have to break up your 
application into smaller modules that can be debugged separately, or 
use console ODT for debugging. 
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The PASDBG and MACDBG debugger service modules occupy no more than 890 
bytes of the application's memory image. However, all application 
programs written in MicroPower/Pascal will become a few percentage 
points larger when the debugging option is enabled in the compiler. 


2.1.7 Configuring the Hardware for Application Debugging 


Be sure the hardware is configured properly and the system 
configuration is operable. Hardware configurations for specific 
environments and uses of the KXT11-C are discussed in succeeding 
chapters of this manual. Full information on all KXT11-C options and 
how to configure the hardware can be found in. the KXT11-CA User's 
Guide hardware reference manual. 


2.1.7.1 KXTI11-C Debugging Configuration —- The following steps 
describe the hardware configuration requirements for the KXT11-C. 


1. Set the base address of the TPR in the arbiter's (Q-BUS) I/0 
page using the system ID switch and the base address range 
jumper on the KXT11-C. Be sure the addresses you select do 
not conflict with those assigned to another KXTI1I-C or with 
other Q-BUS devices. Appropriate address selection depends 
on the peripheral processor's environment. 


2. Select the appropriate boot/self-test power-up option with 
the boot/self-test switch. The boot options permit execution 
from ROM, booting from a TU58, waiting for boot-and-load over 
the Q-BUS, and console ODT operation. The self-test options 
determine whether self-tests, ROM tests and 1/0 loopback 
tests are performed before booting the application. 


3. Configure the I/O ports used by your application. Each I/0 
port has several optional configurations. These are fully 
described in the KXT11-CA User's Guide hardware reference 
manual, and discussed as they relate to each 
MicroPower/Pascal handler in the MicroPower/Pascal Runtime 
Services Manual and the MicroPower/Pascal System User's 
Guide. 


4. Select the appropriate KXT11-C memory map. This is discussed 
in Chapter 3 for MicroPower/Pascal applications. If you are 
building a ROM application, it is advisable to start 
debugging with a RAM configuration so you can set breakpoints 
in memory locations that will ultimately reside in ROM. 


2.1.7.2 System Hardware Debugging Configuration - The system 
configuration required for debugging a KXT11-C application consists of 
the KXT11-C to be debugged, the arbiter CPU, and its Q-BUS I/0 
devices, if any. If you are using PASDBG or MACDBG, you must connect 
a serial asynchronous communication line between the host system 
(RT-~11, RSX-11, VMS) and the KXT11-C console port. Otherwise, use the 
peripheral processor's console ODT by connecting a terminal to its 
console port. 
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When you use MicroPower/Pascal software in the arbiter and_ the 
KXT11-C, you can connect multiple invocations of PASDBG running on one 
or more host processors (depending on your host operating system) to 
the arbiter and KXT11-C processors over separate serial lines. This 
is the best way to debug peripheral processor applications. You can 
also use a single invocation of PASDBG and a terminal to debug several 
targets. Refer to Section 3.6 for detailed information. 


2.1.8 Testing and Debugging the Application 


Run the arbiter or the KXT11-C application with the communication test 
process until you detect an error; then use a debugger to isolate the 
error. If you use PASDBG you can debug your application symbolically, 
setting breakpoints, examining the state of the application, changing 
the contents of memory locations, and controlling the execution of the 
application. If you use console ODT, you must use octal numbers and a 
memory load map. 


2.1.9 Completing the Test Cycle 

Repeat the preceding procedures (Sections 2.1.1 through 2.1.8) for 
each processor used in the application system. When you are through 
with this procedure, you will be confident that each processor 
application is running correctly (to the extent that this can be 


verified with test programs). You can then proceed to testing 
sections of the peripheral processor application together. 


2.1.19 Testing and Debugging the Integrated Application System 


After completing the test cycle described above, integrate all the 
application system components as follows. 


1. Remove all test processes. 


2. Configure the peripheral processor system hardware and _ the 
debugging equipment. 


3. Build a debugging configuration of the software including the 
actual communication processes. 


It is this stage of debugging where multiple invocations of PASDBG are 
useful. If you tested the individual processes well, this phase 


should proceed easily with most of the problems being isolated in the 
communication process. 


2.1.11 Building the Final Application System 
For the final application configuration: 
e Remove any debug aids. 


e Generate an optimized kernel. 
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@ Decide how the final application will be loaded. 


The arbiter and KXT11-C applications must be loaded. For the arbiter 
application, you can use mass storage, down-line loading, or ROM. The 
software to support arbiter application loading depends on _ the 
facilities provided by the arbiter's operating system 
(MicroPower/Pascal, RT-11l, or RSX-11). 


KXT11-C software provides facilities for loading your application from 
the following media. 


@e Memory-image binary files on a Q-BUS mass storage device using 
the KXT_LOAD procedure, the KUI program or other user-created 
load program issuing commands to the native firmware through 
the command registers of the TPR 


e Native ROM on the KXT1l1-C 


e TU58 DECtape II cartridge tape subsystem or other RSP (radial 
serial protocol) device connected to the KXT11-C 


Your choice depends on your application requirements. 


2.1.12 Configuring the Final Application System Hardware 


Review your final hardware configuration. You may need to select a 
memory map that is different from the one used during debugging. Make 
sure there are no CSR and vector address conflicts in the arbiter. 
Compare the CSR and vector assignments of devices you add for 
application loading with those assigned to the KXT11-C processors in 
the system. 


2.2 STAND-ALONE PROCESSOR APPLICATION DEVELOPMENT CYCLE 


The stand-alone application development cycle is the same as_ the 
application development cycle for traditional LSI-1l11 systems. 
Specific information relating to hardware and software configurations 
for KXT11-C stand-alone operation is included in succeeding chapters. 


CHAPTER 3 


PROGRAMMING A KXT11-C USING MICROPOWER/PASCAL 


Developing an application for the KXT11-C when using MicroPower/Pascal 
is Similar to developing other MicroPower/Pascal applications, with 
the following major differences. 


e When using the MPBLD utility you must specify that the target 
‘processor is a KXT11-C. 


@e The MicroPower/Pascal device handlers for the KXT11-C are in 
the DRVK.OBJ library. 


@e You will debug and test a target system that has multiple 
processors. 


e Separate memory images (.MIM files) must be built for each 
processor in the application system; one for the arbiter 
processor (if the arbiter will run MicroPower/Pascal) and one 
for each KXT11-C. 


3.1 KXT11-C SYSTEM FILES 


KXT11-C software for MicroPower/Pascal consists of %INCLUDE files, 
device handler interface routines, prefix files, and device handler 
modules (refer to Table 3-1). 


ZINCLUDE files define Pascal device-handler interface routines and the 
standard I/0 packet structures that the device handlers use. You 
include these files in your program with the INCLUDE command so you 
can use the associated interface routine or packet. 


Device handler interface routines provided in the run-time hardware 
support library (RHSLIB.OBJ) perform all message construction, 
semaphore creation, queue signaling, and queue waiting needed to. send 
and receive commands or data to and from the device handler. Using 
these interface routines, or the MicroPower/Pascal file system, 
greatly simplifies the programming of your application. 


Prefix files configure I/O device handler operating characteristics 
and cause the inclusion of the device handler in the application 
image. When you use the MicroPower/Pascal utility program MPBLD, you 
select handlers by specifying the prefix file of the handler to be 
included. This file may be a MicroPower/Pascal-supplied file or a 
customized version of a MicroPower/Pascal-supplied file. Also, when 
using a device handler interface routine, you must include RHSLIB.OBJ 
as an additional library module. Chapters 5 and 6 of the 
MicroPower/Pascal System User's Guide provide complete information on 
using the MicroPower/Pascal libraries and bootstraps. 


Table 3-1: 
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KXT11-C System Files Provided with MicroPower/Pascal 





File 


Description 





CKPFX.MAC 


CFDKTC.MAC 


CLKLIB.PAS 


DDPFXK.MAC 


DRVK.OBJ 


DRVM.OBJ 


DRVU.OBJ 


IODEF.PAS 


IOPKTS.PAS 


KKPFXK.MAC 


KKINC. PAS 


KXPFX.MAC 


Prefix file for KXT11-C line-frequency clock (CK) handler 
(standard MicroPower/Pascal clock handler). 


Sample KXT11-C system configuration file that specifies 
all features, handlers, and debugging support. Used in 
generation of installation verification program, and 
peripheral processor verification program. 


sINCLUDE file for device interface routines that access 
clock (CK) handler. 


Prefix file for TU58 DECtape II (DD) device handler. 


Device handler object module library for KXT11-C devices. 


‘Contains KK, DD, QD, XL, XS, YK, and CK device handler 


modules. Use this library in merge step when building 
device handler modules into your application. 


Device handler object module library for mapped arbiter 


applications. Contains arbiter Q-BUS (KX) device handler 
and other standard MicroPower/Pascal device handler 
modules. Use this library in merge step when building 


arbiter application's device handler modules. 


Device handler object module library for unmapped arbiter 
applications. Contains arbiter Q-BUS (KX) device handler 
and other standard MicroPower/Pascal device handler 
modules. Use this library in merge step when building 
arbiter application's device handler modules. 


ZINCLUDE file that defines common I/0 definitions for 
Pascal KXT11-C-resident device handler %INCLUDE files. 
Used when compiling KXT11-C device handlers written in 
Pascal and when using KXT11-C MicroPower/Pascal device 
handler interface routines described in Appendix H of 
MicroPower/Pascal Runtime Services Manual. 


SINCLUDE file that defines standard Pascal I/0 packet 
structure used by KX device handler and the other standard 
Pascal arbiter-resident device handlers. Use this file 
when compiling Pascal device handlers and user programs to 
run on arbiter. 


Prefix file for KK (KXT11-C-resident two-port RAM) device 
handler. 


SINCLUDE file defining device handler interface routines 
that access KK (KXT11-C-resident two-port RAM) device 
handler. 


Prefix file for KX (arbiter-resident two-port RAM) device 
handler. Used in peripheral processor verification and 
demonstration programs. 
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File Description 


KXINC.PAS SINCLUDE file defining device handler interface routines 
that access KX (arbiter-resident two-port RAM) device 
handler. 


KXLINC.PAS %INCLUDE file defining Pascal-callable procedure KXT_LOAD 
that loads KxT11-C from arbiter. 


QDPFXK.MAC Prefix file for DMA transfer controller (DTC) device 
handler (QD). 


QDINC.PAS SINCLUDE file defining device handler interface routines 
that access DMA transfer controller (QD) device handler. 


RHSLIB.OBJ Device-handler interface routine object module library. 
Contains modules for KK, KX, QD and YK device handler 
interface routines, KXT LOAD (load KXT11-C from arbiter) 
procedure, and standard MicroPower/Pascal device handler 
interface routines. Use this library in merge step when 
building Pascal program compiled with %INCLUDE file 
KKINC.PAS, KXINC.PAS, QDINC.PAS, YKINC.PAS, KXLINC.PAS or 
RHSDSC.PAS. 


XLPFXK.PAS Prefix file for asynchronous’ serial line (XL) device 
handler for KXT11-C serial devices. 


XSPFXK.PAS Prefix file for synchronous serial line (XS) device 
handler. 


XSINT.MAC Source file for synchronous serial line (XS) device 
handler's interrupt service routine. Provided as 
instructional aid in creating application-specific version 
of XS device handler. 


XSDRVK.PAS Source file for synchronous serial line (XS) device 
handler. Provided as instructional aid in creating 
application-specific version of XS device handler. 


YKPFXK.MAC Prefix file for parallel port and counter-timer (YK) 
device handler. 


YKINC.PAS SINCLUDE file defining device handler interface routines 
used with parallel I/0 (YK) device handler. 


PPVFY.COM Command file that generates and loads peripheral processor 
verification and demonstration programs. In RSX-11 
versions of MicroPower/Pascal kit, has .CMD file type. 


IOPVFY.PAS Pascal source file for KXT11-C half of peripheral 
processor verification and demonstration programs. 


ARBVFY.PAS Pascal source file for arbiter half of peripheral 
processor verification and demonstration programs. 





3.2 BUILD PROCEDURE 


‘Building an application that runs on the kKxXT11-C is similar to 
building Q-BUS processor applications. You can build your application 
automatically using the MPBLD command procedure, or build your 
application manually issuing commands to MERGE, RELOC, MIB, the 
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MACRO-11 assembler, and the MicroPower/Pascal compiler. In manual 
builds, you must specify the appropriate library file names to each 
build program. In contrast, MPBLD automatically supplies the 
appropriate file specification for a corresponding build step, 
depending on CPU type and other entries. 


Chapters 5 and 6 of the MicroPower/Pascal System User's Guide provide 
complete information on using the MicroPower/Pascal libraries and 
bootstraps. 


3.2.1 Optimizing the Kernel 


Optimizing the kernel in the KXT11-C environment is the same as_ for 
the LSI-11 environment. An optimized kernel is a customized version 
of the kernel that contains only the primitives your application uses; 
unused primitives are discarded. Building an- optimized kernel 
minimizes its size and consequently the amount of memory the 
application will occupy. 


You can optimize the kernel as one of the final application building 
steps after debugging is complete. If memory space is at a premium, 
you can eliminate some of the kernel's primitives before debugging. 
When you specify YES in the OPTIMIZE parameter of the SYSTEM macro, 
you can list in the PRIMITIVES macro the kernel primitives your 
application uses. You can then determine how much RAM and ROM your 
application occupies by obtaining the maps generated by the MIB and 
RELOC utilities. These maps show the size of the RAM and ROM used by 


the MicroPower/Pascal kernel, and all other processes. As you omit 
primitives from the list, you can obtain new copies of the maps to 
determine the additional amount of memory reclaimed. Alternatively, 


you can use an application building style that automatically 
configures the kernel primitives used by your application code. 
Chapter 7 of the MicroPower/Pascal System User's Guide describes this 
procedure. 


3.2.2 Building KXT11-C Applications with MPBLD 


MPBLD is an interactive command procedure utility that builds 
application images. (Refer to Appendix B of the MicroPower/Pascal 
System User's Guide for more information about MPBLD.) The following 
paragraphs list MPBLD questions for building KXT11-C applications and 
discuss the appropriate answers. Message text enclosed by angle 
brackets (<>) represents information the MPBLD procedure supplies. 


Questions 1 through 5 do not relate exclusively to the KXT11-C. 


Question 6: Do you wish to modify <kernel configuration file>? [no]: 


If you have not created a configuration file that includes’ the 
KXT11-C, or if you are not using the standard CFDKTC.MAC configuration 
file supplied with MicroPower/Pascal, you should answer YES to this 


question. This allows you to create a configuration file or edit a 
copy of the standard configuration file to include the kKxT11-C 
parameters. If you answer NO to this question, the kernel will be 


built with the configuration file parameters that exist in the file. 
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For KXT11-C applications you must specify the following macros’ and 
arguments. 
PROCESSOR 
You must specify the following parameters. 
mmu=NO 
type=KXTLIC 


vector=<address> 


where <address> is the address of the first free memory location 
above the highest interrupt vector used by the application. 


MEMORY 


Specify the memory allocation scheme you selected. The KXT11-C 
has eight different jumper-selected memory mapping schemes; maps 
8 through 7 described in Section 3.3.1. 


KXT1LIC 

Select parameters required for your application. Be sure the MAP 
Parameter agrees with the memory configuration you specified in 
the MEMORY macro. 


DEVICES 
Specify the interrupt vectors of the devices used by the 


application. Appendix B lists standard KXT11-C device vector 
assignments. 


Question 7: Satisfied with edit? [yes]: 
At this point you exit the editor and proceed to question 8 (YES) or 
repeat the editing session (NO). If you answer NO, you return to the 


editor with the originally specified file as input. This question is 
asked each time you leave the editor. 


Questions 8 through 19 do not relate exclusively to the KXT11-C. 


Question 11: Mapped image? [no]: 

Answer NO. The KXT11-C has no memory mapping hardware. 

Question lla: Is the target a KXT11-C? [no]: 

Answer YES. This answer selects the KXT11-C device handler library 


DRVK.OBJ. 


Question 12 does not relate exclusively to the KXTI11-C. 
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Question 13: Does this system contain any ROM? [no]: 


If the KXT11-C contains ROM, answer YES; otherwise, answer NO. 


Question 14: What is the base address of RAM (octal address)? : 


Enter the lowest address assigned to RAM. The answer you give will 
depend on the KXT11-C memory map you selected. Specify the address as 
an octal number. 


Question 15: Instruction set hardware? {NHD, FPP, EIS, FIS} 
[default]: 


Since the KXT11-C does not support FPP, EIS or FIS hardware, answer 


NHD or <RET>. The default is NHD because you answered NO to question 
Ls 


Question 16: LSI-11/2 mode on compilations? [no]: 


Answer NO. The processor is not an LSI-11/2. 


Question 17: Handler Prefix filespec? : 


This question is the first of a series of questions (17 through 29) 
that allow you to specify a standard DIGITAL-supplied KXT11-C device 
handler and tailor it to your particular needs by editing its prefix 
file. The sequence will repeat until you have no further device 
handlers to specify. The MicroPower/Pascal Runtime Services Manual 
describes the standard device handlers. The associated prefix files 
are described in the MicroPower/Pascal System User's Guide. 

If your application uses one of the KXT11-C devices and you are not 
providing your own handler for this device, enter the name of one of 
the following DIGITAL-supplied KXT11-C device handler prefix files. 
If you are not using one of these handlers or you have entered all the 
handlers to be used, answer <RET>. MPBLD will then skip to question 
21. 


Prefix 
Filename Device 


CKPFX.MAC Line clock 

DDPFXK.MAC TU58 DECtape II 

KKPFXK.MAC KK (KXT11-C-resident two-port RAM) handler 
QDPFXK.MAC DMA transfer controller 


XLPFXK.MAC Asynchronous serial lines SLU1, SLU2 channel A_ and 
' SLU2 channel B 


XSPFXK.PAS Synchronous serial line 


YKPFXK.MAC Parallel I/O ports and counter-timers 
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Question 18: Is this a Pascal-implemented handler? [no] : 


Answer YES if you specified the XSPFXK.PAS prefix file in the previous 
question. 


Question 19: Do you wish to modify <prefix filespec>? [no]: 


Answer YES if you want to edit the prefix file specified in question 
17 to include handler features other than the default features. Refer 
to the MicroPower/Pascal System User's Guide for device-handler prefix 
file descriptions and to the MicroPower/Pascal Runtime Services Manual 
for device handler descriptions. 


Question 29: Satisfied with the edit? [yes]: 

At this point exit the editor and return to question 17 (YES) or 
repeat the editing session (NO). If you answer NO, you return to the 
editor with the originally specified file as input. This question is 


asked each time you leave the editor. 


The remaining MPBLD questions do not relate exclusively to the 
KXT11-C. 


3.3 SOFTWARE AND HARDWARE CONFIGURATION GUIDELINES 


This section tells you how to configure the MicroPower/Pascal software 
and KXT11-C hardware. There are four main areas of concern: 


1. The location of RAM and ROM 
2. The system configuration, stand-alone or peripheral processor 
3. The I/O device options 


4. The bootstrap start-up option 


3.3.1 Configuring Memory 


KXT11-C native memory has eight jumper-selectable configurations 
(maps) as shown in Figure 3-l. Each map defines a particular 
combination of native (local) RAM and user-installed RAM or ROM 
residing in the user sockets of the KXT11-C. 
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177777 


2KB oS ae PAGE 2KB I/O PAGE 
4KB Native | KB Native Firmware ROM | ROM 4KB Native Firmware ROM 
2KB Self-test Overlay 160000 2KB Self-test Overlay 


, Reserved 
8KB 8KB 

Native Native 64 Bytes 

ie Firmware 

) Extension 140000 Yea 

: Reserved 64 F cHeserved Cheyes | . 
120000 
8 : 


ie | KB 16KB 16KB 


User User User User 
cy | ROM/RAM | ROM/RAM | ROM/RAM 100000 


Reserved 64 Bytes 





60000 
40000 
20000 
| 0 ROM/RAM 
MAP OQ MAP 1 MAP 2 MAP 3 MAP 4 MAP 5 bas 6 MAP7 


Figure 3-1: KXT11-C Memory Map Configurations 


3.3.1.1 Memory Configuration Steps - When you configure KXT11-C 
memory, you must specify parameters in the software configuration file 
and install jumpers on the KXT11-C circuit board: 


1. Select a map according to the requirements of your 
application. 


2. Specify the number of the map you selected in the KxT11C 
configuration file macro. 


3. Install additional ROM or RAM in the user sockets. 
NOTE 


If your application uses ROM, consider 
substituting RAM in its Place during 
debugging so you can use the PASDBG debugging 
program. 
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Specify, in the configuration file's MEMORY macro, each 
contiguous block of RAM and ROM defined by the selected map 
and the ROM or RAM installed in the user sockets. 


Install the map selection jumpers on the KXTI11-C circuit 
board. (The KXT11-CA User's Guide hardware reference manual 
shows the location of these jumpers.) 


Select an appropriate setting for the boot/self-test switch 
(see Table 3-3). 


3.3.1.2 Memory Selection Rules - MicroPower/Pascal software can use 
any KXT11-C memory map option as long as you observe the following 
configuration rules. 


1. 


You can select any memory map for RAM-only applications that 


is appropriate for the type of RAM devices installed in the 
user sockets. : 


You can select maps 4, 5, 6, or 7 for MicroPower/Pascal 
applications that use ROM. MicroPower/Pascal memory 
allocation rules require that you configure all ROM in memory 
addresses lower than those assigned to RAM. Thus, you should 
not specify maps 8 to 3 if your MicroPower/Pascal application 
uses ROM. 


If your application will be loaded from TU58 DECtape II, you 
must configure RAM to start at address @. 


Do not configure your application to use the highest 64 bytes 
of native RAM. This area is reserved for KXTI1-C native 
firmware. The location of this 64-byte area depends on which 
memory map you select with the boot/self-test switch (see 
Figure 3-1). If you are going to use RAM in the user 
sockets, assign it to low memory addresses (maps 4 to 7). In 
this way the reserved 64-byte area will reside at the highest 
RAM locations rather than within the RAM address range. 


Do not configure your application to use nonexistent memory 
addresses (address space identified as NXM in Figure 3-1). 


Never configure the 8KB block of memory addresses shown in 
maps 3 and 6 and designated 8KB Native Firmware Extension. 
These addresses reference locations in the native firmware 
socket that are outside the address space of the native 
firmware ROM provided by DIGITAL. 


Table 3-2 summarizes MicroPower/Pascal map usage. 
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Table 3-2: MicroPower/Pascal Usage of KXT11-C Memory Maps 





Map Usage 





Q 


32KB of native RAM; 4KB RAM in user sockets mapped high. Do not 
allocate memory between 77799 and 77777. 


1 32KB of native RAM; 8KB RAM in user sockets mapped high. Do not 
allocate memory between 77789 and 77777. 

2 32KB of native RAM; 16KB RAM in user sockets mapped nag: Do not 
allocate memory between 77798 and 77777. 

3 32KB of native RAM; 16KB RAM in user sockets iapoed high. Do not 
allocate memory between 77798 and 77777. 

4 32KB of native RAM; 4KB ROM/RAM in user sockets mapped low. Do 
not allocate memory between 1377998 and 137777. 

5 32KB of native RAM; 8KB ROM/RAM in user sockets mapped low. Do 
not allocate memory between 137798 and 137777. 

6 32KB of native RAM; 16KB ROM/RAM in user sockets mapped low. Do 
not allocate memory between 137799 and 137777. 

7 24KB of native RAM; 32KB ROM/RAM in user sockets mapped low. Do 


not allocate memory between 15779898 and 157777. 





3.3.2 Using Battery Backup 
The battery backup feature of the KXT11-C preserves the contents of 


the native RAM during power failure so that the application program 
can recover after a power failure. 


3.3.2.1 Configuration Considerations - You must configure the 
hardware and software to set up RAM for battery backup operation. 


To configure the hardware: 
e Obtain an appropriate 5V battery. 
e Connect the battery to the KXT11-C backplane. 


e Install the battery backup jumper on the KXT11-C circuit 
board. 


e Install ROM in the user sockets and configure the jumpers 
appropriately for the ROM devices used. 


e Select a memory map with the ROM starting at location @. 


Refer to Chapter 6 of the KXT11-CA User's Guide hardware reference 
manual for detailed information. 
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To configure the software: 


ee Edit the kernel configuration file so the POWER parameter of 
the KXT11C macro specifies NONVOL (that is, POWER = NONVOL). 
This causes the appropriate kernel power failure and power 
restoration routines to be built into your application. 


e Specify the use of RAM and ROM using the MEMORY macro. 
e Build the system so all code resides in ROM. 


Configuring memory in this way affects the way you use PASDBG (see 
Section 3.6.7). 


3.3.2.2 Programming Considerations - To make effective use of battery 
backup, you must design your application with the following 
information in mind. 


On restart after a power failure, the MicroPower/Pascal kernel 
completely initializes itself and the user's application; it does not 
attempt to recover the application's context. Your application must 
recover its own context after a power failure. I/0 transactions that 
occurred during the failure are lost. 


The kernel's power-up routine generates an interrupt and maintains a 
recovery indicator to facilitate application recovery. Each time 
power is restored, the kernel's power-up routine generates a trap 
through vector 214. Whether or not your application responds to the 
interrupt depends on the actions that need to be performed when a 
power restart occurs. If no action is required, the application can 
ignore the interrupt. The application's initialization routines may 
also test the kernel's one-word recovery indicator (KXTSRI). If the 
value is nonzero, a power restart rather than a cold start is in 
progress. If your application requires a direct response to the 
interrupt, you must write a power-failure interrupt service routine 
that connects to this vector (CONNECT INTERRUPT in Pascal or CINTS in 
MACRO-11). The routine can examine KXTSRI to determine whether a cold 
start or recovery occurred so it can direct an action to take after 
the power failure. When your interrupt routine completes, the native 
firmware will reinitialize to reconfigure the peripheral controller 
circuits which are not protected during a power failure. 


In another recovery technique your application can maintain a system 
of I/O status flags and perform buffer validation after a restart from 
a power failure. Refer to the description of the kKXT11C macro in 
Chapter 4 of the MicroPower/Pascal System User's Guide for additional 
programming information. 


3.3.3 Configuring the KXT11-C System Environment 


This section tells you how to set up the -KXT11-C for its system 
environment. The features you can select include stand-alone 
operation or peripheral processor operation, and the system's start-up 
options (application bootstrap device, console ODT operation, and 
self-test program execution). When you select these features, you 
must configure jumpers and switches on the KXT11-C circuit board and 
change some of the parameters of the KXT1LIC macro in the configuration 
file. 
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The system ID switch and the boot/self-test switch specify to the 
native firmware the desired environmental and operational features of 
the KXT11-C. The boot/self-test switch determines when the self-tests 
will be performed and how the application program will be initialized. 


3.3.3.1 Selecting Stand-Alone or Peripheral Processor Operation - You 
can select stand-alone or peripheral processor operation with the 
system ID switch on the KXTI11-C circuit board. 


To use stand-alone mode, select switch positions @ or 1. In 
stand-alone mode, the two-port RAM (TPR) is disabled since no Q-BUS is 
required. To use peripheral processing mode, select switch positions 
2. “BOs 1S You can configure a maximum of 14 KXT11-C peripheral 
processors in a Q-BUS system by selecting switch positions 2 to 15. 


In peripheral processing mode, the TPR is enabled and connected to the 
Q-BUS. Each switch position selects a different base address for the 
TPR registers in the arbiter's I/O page. The switch selects addresses 
from a high or low range depending on whether or not you install the 
TPR base address jumper on the KXTLI-C circuit board. 


Appendix C lists system ID switch settings and the associated I/O page 
base addresses of the two-port RAM. When selecting the TPR base 
addresses, avoid conflicts between the KXT11-C processor's I/0 page 
registers and I/0 page registers allocated to other devices on the 
application system's Q-BUS. 


Do not configure TPR addresses in the high range for system ID switch 
settings 8 to 15, as many of these addresses are allocated for 
standard devices and processor registers. ; 


Each system ID switch number you select must be unique among all 
system ID switch numbers for KXT11-C processors on the same Q-BUS. 
The number need not be in a continuous sequence with the system ID 
Switch numbers selected for other KXT11-C processors on the Q-BUS. 


Specify the CSR address implied by the system ID switch and TPR base 
address jumper setting you select in the KX device handler prefix 
file. You can insert this information in the file manually with an 
editor or automatically during execution of MPBLD (described in 
Appendix B of the MicroPower/Pascal System User's Guide). 


3.3.3.2 Selecting KXT11-C Initialization and Self-test Options - 
KXT11-C firmware provides initialization and diagnostic self-test 
functions that are selected by the boot/self-test switch on _ the 
KXT11-C circuit board. They are power-up features that provide for 
hardware initialization, automatic self-tests, console ODT, 
application bootstrapping, and execution of control routines that 
handle local restart interrupts to allow the arbiter to gain control 
of the kKxXT11-C. Table 3-3 summarizes the boot/self-test switch 
functions. 
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Table 3-3: Initialization/Self-Test Options 


Boot/Self-Test Switch Position* 


Initialize/Test 
Feature @ 1 7 1¢}11)]12)13)144 15 
eit ee ees 


Start-up in ROM | xX 


Boot from TU58 x 

DECtape 

Load RAM from xX xX 

arbiter and run 

Enter debugging x 

(ODT) mode 

Perform user xX 
ROM tests 

Perform auto x xX x xX 

self-tests 

Dedicated test x xX 
mode 

Reserved Pt tt EEE tee tf ff ff 


*Switch positions 7 and 11 to 15 are reserved. If you apply power to 
the KXT11-C with these positions selected, it will not function and 
the LED display will indicate a fatal error. 


3.3.3.2.1 ROM Application Start-up - Boot/Self-test switch positions 
@, 1 and 2 allow you to execute a ROM application. The native 
firmware transfers control to the ROM code by emulating a trap to 
location 24. Consequently you must configure the ROM to start at 
address @ (maps 4 to 7) to assure that the contents of vector 24 are 
preserved. 


Switch position 9 inhibits the automatic self-tests. By using this 
switch position, you can reduce application start-up time toa 
minimum. Choose this position only when necessary to maintain 
acceptable application performance. 


Switch position 1 inhibits the user ROM checksum test. This allows 
you to start an application that was loaded into ROM that contains no 
checksum or that was loaded into ROM with a checksum that was 
calculated by an algorithm that is incompatible with the test. 
Appendix E describes the procedure to use with the DECprom program to 
calculate and program ROM checksums for KXT11-C applications. The 
KXT1I-CA User's Guide hardware reference manual describes the checksum 
algorithm. 


Use switch position 2 if your ROM application supports the user ROM 
checksum test. 
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3.3.3.2.2 TU58 and RSP Bootstrap - If you are going to load your 
application image from a TU58 DECtape II drive or an RSP (radial 
serial protocol) link, select switch position 3. This causes the TU58 
primary bootstrap to execute on power-up and load your application 
using RSP from a TU58 DECtape II subsystem or other system through 
SLUL (DLART). Once the primary bootstrap begins receiving the boot 
block from the TU58, it checks that the first word of the block is in 
the range 24@(octal) to 277(octal). If true, it considers this block 
to be a valid boot block and it loads the remaining blocks into RAM 
and starts the program. If the first word's value is invalid, the 
primary bootstrap continues to check, alternating between unit 9 and 
unit 1, until it finds a valid boot block. 


When your application will be loaded from TU58 DECtape II, you must 
configure RAM to start at address 9. 


3.3.3.2.3 Loading from the Arbiter - You can load your peripheral 
processor application from a system storage device via the arbiter. 
If your arbiter application runs under MicroPower/Pascal, you can use 
the Pascal routine KXT_LOAD described in Appendix H of the 
MicroPower/Pascal Runtime Services Manual. rea your arbiter 
application runs under RSX-11 or RT-l1, you can use the KUI utility 
program described in the KXT11-C Software Toolkit/RSX Reference Manual 
or KXT11-C Software Toolkit/RT Reference Manual. 


Boot/Self-test switch positions 5 and 6 instruct the KXT11-C to wait 
for a command over the Q-BUS from KXT LOAD or KUI. The automatic 
self-tests will be performed first if you select switch position 5; 
they will be inhibited if you select switch position 6. 


3.3.3.2.4 Automatic Self-Tests - The automatic self-tests are a 
subset of the self-test functions that the native firmware provides. 
These tests will run when the boot/self—test switch is in positions l, 
2, 3 and 5. 


The automatic self-tests include a: 
e CPU test 
e RAM test, native and user (if RAM resides in user sockets) 
@e ROM test, native and user (if selected) 


e CSR test, NXM test of all native CSRs and the TPR (read-only 
test) . 


e DMA test, local-to-local DMA transfers 


The tests report diagnostic errors using the LED display on the 
KXT11-C circuit board and the TPR system control registers. The LED 
display reports automatic self-test diagnostic data and general 
KXT11-C status. Control registers 2 and 3 of the TPR contain the test 
status information on completion of the nonfatal tests. Register 2 
indicates which tests failed and register 3 specifies the type of 
failure. Register 3 is overwritten only if an error was encountered, 
and will contain the valid discrete error code for the last test that 
found an error. 
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The native firmware considers failure of the following self-tests as a 
fatal condition and will not allow the application to run. 


e CPU test 

e Native RAM test 

e Native ROM test 

e CSR test (TPR portion) 


The tests report fatal errors only in the LED indicators since the 
firmware disables the TPR under these conditions. 


The results of the remaining nonfatal tests do not prevent the 
application from running and will be reported in the LED display and 
the TPR system control registers. The user application should check 
for these nonfatal error conditions to see if they affect the 
application. Appendix F describes the procedures to follow. 


Chapter 6 of the KXT11-CA User's Guide hardware reference manual 
discusses the meaning of all LED displays;: Chapter 5 in that document 
describes the TPR registers and associated error codes. 





If you do not select the automatic self-tests, you can reduce 
application start-up time to a minimum. However, these tests are 
useful diagnostic tools. You should bypass them only when necessary 
to maintain acceptable application performance. 


3.3.3.2.5 Debugging (ODT) Mode - When you use boot/self-test switch 
position 4, the KXT11-C enters console ODT through SLU1 (DLART). 
Select this switch position when you want to debug your application 
with PASDBG. 


3.3.3.2.6 Dedicated Test Mode - This mode is for dedicated diagnostic 
testing; the tests permit no execution of application code. You 
select the tests with boot/self-test switch positions 8, 9 and 1@. 
These switch positions cause RAM to be mapped to low memory addresses 
by overriding the selected memory map jumper settings. ROMS jumpered 
for high memory mapping are mapped to their corresponding positions in 
low memory. 


Switch positions 8 and 9 select the automatic self-tests and I/O port 
loopback tests; position 9 includes the ROM test. You must install 
loopback connectors on the I/0 ports for these tests. 


Switch position 18 selects the automatic self-tests, then causes’ the 
KXT11-C to wait for self-test commands through the TPR from the 
arbiter. 


Chapter 6 of the KXTI1I-CA User's Guide hardware reference manual 
provides further information. 


3.4 1/0 PROGRAMMING AND CONFIGURATION CONSIDERATIONS 


The following subsections discuss how you can use the device handlers 
DIGITAL provides for the kKxXT1l1-C with MicroPower/Pascal software. 


PROGRAMMING A KXT11-C USING MICROPOWER/PASCAL 


Examples illustrate features of these handlers that differ from the 
non-KXT11-C MicroPower/Pascal device handlers. 


3.4.1 Using the Parallel I/O (YK) Handler 

The YK device handler operates the parallel I/O and _ counter-timer 
controller on the KxXT11-C. It allows your MicroPower/Pascal programs 
to interface with the two 8-bit parallel ports, the 4-bit 
special-purpose I/O port, and the three independent 16-bit 
counter-timers. The handler provides the functions of read, write, 
pattern recognition, DMA read, DMA write, counter-timer set, 
counter-timer read, and counter-timer clear. 


The parallel I/O port has configuration options you can select by 
editing the handler's prefix file. Many of these options interact 
with one another in subtle ways. You must be thoroughly familiar with 
the operation of this device and with the configuration rules before 
building an application that uses the YK device handler. (Refer to 
the KXT11-CA User's Guide hardware reference manual and Chapter 4 of 
the MicroPower/Pascal System User's Guide.) 





The parallel I/O port can read and write streams or individual bits of 
data using its event synchronization options. Your programs can 
access the YK handler from MicroPower/Pascal or MACRO-11 routines by 
using the standard primitive I/0 requests or the MicroPower/Pascal 
device handler interface routines listed below. 


YK PORT READ -- Reads data from a parallel port 

YK_PORT WRITE -- Writes data to a parallel port 

YK_SET PATTERN -- Sets pattern recognition modes for a parallel 
port 

YK_SET_TIMER -- Sets a timer to an initial value, triggers a 


timer after setting it, or sets a timer to periodically signal a 
binary semaphore 


YK_READ TIMER -- Reads a timer's or counter's current count 
YK_CLEAR TIMER -- Deactivates a timer or counter 


Refer to Chapter 4 and Appendix H of the MicroPower/Pascal Runtime 
Services Manual for detailed information. 


Typical parallel I/O port applications include: 


e Transferring a series of bytes or words through a port with 
handshake protocol 


e Setting or reading the bits of external state lines 
e Generating a time base to software 
e Generating a waveform for external output 


e Counting pulses from an external input 
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The paragraphs that follow provide examples to illustrate these 
applications. All examples use the MicroPower/Pascal device handler 
interface routines listed above. 


3.4.1.1 Transferring a Series of Bytes or Words Through a Port - This 
example illustrates how a program can send a stream of parallel data 
from a buffer to an output port connected to a parallel printer. The 
example makes full use of the parallel I/O ports. The printer must 
Operate under handshake signal control and the user's program must 
monitor the printer's error .-status data and send control/indicator 
data to it. 


Parallel (/O Counter—Timer 











Port B 
bits 
<7:0> 


INAH 


Port B Acknowledge Handshake Input 


Port B Data Available Handshake Output 
Parallel 


Printer 








Handshake Lines: 










Device Error 
Status Lines 


Data Input - 
Lines 


Control/Indicator 
Lines 


Figure 3-2: Sending Data to a Parallel Printer 


Configuration 


Figure 3-2 shows the external connections between the parallel I/0 
port and the printer. The listing of the YK handler prefix file that 
follows shows you how to specify this configuration. 


Port A is configured as a bit port. The least significant bits (@ to 
3) are configured as output lines to the printer's control and 
indicator lines. The most significant bits (4 to 7) are configured by 
- default as input lines to receive error input signals from the 
printer. Pattern matching is specified to detect changes in error 
input signals. 
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Port B is configured as an output port with interlocked handshake for 
the data bytes going to the printer. 


Port C is configured as a bit port with bit 9 as an output for the 
printer's data-accepted line. Bit 1 is configured by default as an 
input for the printer's ready-for-data line. 


-MCALL YKCIS 
YKCIS +; Beginning of Prefix File 


; Port A Setup 


Port A is a Bit Port. 

Least Significant 4 bits are outputs. 
Pattern Recognition to detect 
changes in Error Input Lines. 


YKCPS$ CHAN=A, PTYPE=YKSBIT 
YKCPS CHAN=A, OUT=17 
YKCPS CHAN=A, PAT=TRUE 


me us SB NO 


7 Port B Setup 


YKCPS CHAN=B, PTYPE=YKSOUT 
YKCPS$ CHAN=B, HSH=YKSINL 


Port B is an Output Port 
with Interlocked Handshake. 


=e NO 


7 Port C Setup 


Port C is a Bit Port. 
Bit 1 is a Handshake Output. 


YKCPS CHAN=C, PTYPE=YKSBIT 
YKCPS CHAN=C, OUT=2 


ue Ne 


YKCES End of Prefix File 


ue 


MicroPower/Pascal Program Fragment 


The following MicroPower/Pascal program fragment illustrates how a 
program can write a line of data to the YK handler configured to 
operate a parallel printer. 


The SINCLUDE commands in the following example refer to the RT-11 

logical device LB:. If your host environment is RSX-11 or VMS, 

substitute the appropriate logical device. Refer to the 

MicroPower/Pascal Installation Guide for this information. 

include 'LB:IODEF' { get the INCLUDE file for the common} 
{ I/O definitions} 

Zinclude 'LB:YKINC'! { get the INCLUDE file for the 

{ device handler interface routines} 


VAR 
LP DATA : PACKED ARRAY [1..512] OF CHAR ; { LP data } 
DATA_LEN : INTEGER ; { number of characters} 
RESULTS : IOSSTATUS ; { write results 

BEGIN 


RESULTS := YK_PORT WRITE 
( PORT NUM := PORTB , 
BUFFER := LP DATA , 
BYTE COUNT := DATA LEN ) ; 
END ; 7 ze 
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3.4.1.2 Transferring Data to and from Analog Devices - This is an 
example of analog-to-digital (A/D) and digital-to-analog (D/A) I/0. 
It illustrates how a program can receive a constant flow of 8-bit A/D 
data, filter the data in some way, then send the reduced data to a D/A 
converter. The example uses two external input clocks to control the 
rate of flow of input and output data individually. 


This example assumes that: 


An input buffer cannot be filled with incoming data in less time 
than it takes to filter and process the previous input buffer. 


The rate of data output equals the input data rate times the 
ratio of output buffer size divided by input buffer size. 


These assumptions prevent input data from being lost and keep output 
data flowing continuously. The example does not incorporate a method 
of detecting a violation of either assumption which could occur if the 
external clocks are misadjusted. 


Parallel /O Counter—Timer 
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Figure 3-3: Transmitting Data to and Receiving Data from Analog 
Devices 


Configuration 


Figure 3-3 shows the external connections between the parallel tI/0 
port and the A/D and D/A converters. The listing of the YK handler 
prefix file that follows shows you how to specify this configuration. 


The YK configuration macros set up port A as an input port with a 
strobed handshake and port B as an output port with a strobed 
handshake. 
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-MCALL YKCIS 


YKCIS Beginning of Prefix File. 


=e 


,Port A Setup 


YKCPS CHAN=A, PTYPE=YKSINP, HSH=YKSSTR Port A is an input port 


with strobed handshake. 


me me 


7Port B Setup 


YKCPS$ CHAN=B, PTYPE=YKSOUT, HSH=YKSSTR Port B is an output port 


with strobed handshake. 


me ne 


7;Port C Setup 


YKCPS CHAN=C, PTYPE=YKSBIT, OUT=<YKSB1+YKSB3> ; Port C is a bit port 
; with bits 1 and 3 set for 
; Output 


YKCES ; End of Prefix File 


MicroPower/Pascal Program Fragment 


The following MicroPower/Pascal program fragment illustrates how a 


program can use the YK handler to read data from an A/D converter and 
write data to a D/A converter. 


The $INCLUDE commands in the following example refer to the RT-11 
logical device LB:. If your host environment is RSX-11 or VMS, 
substitute the appropriate logical device. Refer to the 
MicroPower/Pascal Installation Guide for this information. 


[ SYSTEM(MICROPOWER)] PROGRAM C3EX2 ; 


_{SNOLIST} : 
include 'LB:IODEF' . { get the INCLUDE file for the common} 
{ 1/0 definitions} _ 
%include 'LB:YKINC' { get the INCLUDE file for the 
{ device handler interface routines} 
{SLIST} 
CONST 


IN BUF SIZE = 256 ; {size of input buffers } 

LAST BUF = 3 ; { number of input/output buffers pairs, a minimum of 
3 are needed because the filter will (at certain 
points in time) be reading data from the end of a 
first input buffer and the beginning of a second 
at the same time. Meanwhile the YK handler will 
be filling a third. } 


OUT BUF SIZE = 64 ; { The size of the output buffers must be proportional 
to the data reduction ratio. } 


TYPE 


IN DAT BUF = PACKED ARRAY [1..IN BUF SIZE] OF BYTE RANGE ; { data buffer } 
IN_DAT AREA = RECORD , 


DAT LEN : UNSIGNED ; { length of buf, or # of bytes in it} 
DAT SECT : IN DAT BUF; { input data buffer } 
END ; ; 


OUT_DAT BUF = PACKED ARRAY [1..OUT_BUF_SIZE] OF BYTE RANGE; { out buffer } 
OUT DAT AREA = RECORD 


DAT_LEN : UNSIGNED ; { length of buf, or # of bytes in it} 
DAT SECT : OUT DAT BUF; { output data buffer } 
END ; 
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VAR 
IN BLK =: ARRAY [1..LAST_BUF] OF IN _DAT AREA ; { input records } 
OUT_BLK : ARRAY {1..LAST _BUF] OF OUT DAT _AREA; { output records } 
IN_STATUS : IOSSTATUS ; { Input status } 
OUT STATUS : IOSSTATUS ; { output status } 
CURRENT BUF : UNSIGNED ; current buffer being filtered } 


input Reply sem descriptor } 
output Reply sem desc } 
YK reply Packet } 


IN_REPLY DESC : STRUCTURE DESC ; 
OUT REPLY DESC : STRUCTURE DESC ; 
IN REPLY PKT : YK REPLY ; 


{ Beginning of Process } 


BEGIN 
OUT REPLY DESC .ID := NO SEM ; { prevent replies from output} 
IF CREATE QUEUE SEMAPHORE ( DESC 2= IN_REPLY DESC ) THEN 
BEGIN , 
{ Send all the input buffers to the YK handler } 
FOR CURRENT BUF := 1 TO LAST BUF DO 
BEGIN 
IN BLK [ CURRENT BUF J] .DAT_LEN := IN_BUF_ SIZE ; 


IN STATUS := YK _PORT _READ  ( 
~ PORT _NUM := PORTA , 
BUFFER := IN | BLK [ CURRENT BUF ] .DAT_SECT , 
BYTE COUNT := IN BLK [ CURRENT BUF ] .DAT_LEN, 
REPLY := ADDRESS (IN REPLY _DESC )) 3 


END ; 
WHILE { ( IN STATUS . ERROR_CODE = IESNORMAL ) 
AND ( OUT STATUS . ERROR_CODE = IESNORMAL ) ) DO 
BEGIN 
RECEIVE ( VAL DATA := IN REPLY PKT , 
VAL LENGTH := SIZE (YK REPLY) , 
DESC := IN REPLY DESC ) ; 
IF IN_REPLY PKT .STATUS .ERROR_CODE <> IESNORMAL THEN 
IN STATUS := IN REPLY PKT .STATUS 
ELSE 
BEGIN 


{ now go do the filtering of the data coming in from 
IN BLK [ CURRENT BUF ] .DAT SECT and put the results 
into OUT BLK [CURRENT | BUF] .DAT SECT . Also put 
the number of output bytes into the length entry of 
OUT BLK. } 


OUT_ STATUS := YK PORT WRITE ( 
PORT | NUM := PORT B , 
BUFFER := OUT _BLK { CURRENT BUF). DAT SECT , 
BYTE COUNT: =OUT_ BLK { CURRENT BUF 1s DAT_LEN , 


REPLY := ADDRESS (OUT REPLY DESC ) ) ; 
IF CURRENT BUF = LAST BUF THEN 
CURRENT BUF := CURRENT BUF + 1 
ELSE 
CURRENT BUF := 1 ; 


IN BLK [ CURRENT BUF ] .DAT_LEN := IN BUF_SIZE ; 

IN | STATUS = YK_PORT_READ ( 
PORT NUM := PORTA , 
BUFFER := IN BLK [ CURRENT BUF ] .DAT_SECT , 
BYTE COUNT 2= IN_BLK [ CURRENT BUF ] .DAT_LEN, 
REPLY := ADDRESS (IN REPLY DESC ) ) ; 

END ; 

END ; 
END |; 
END. 


3.4.1.3 Receiving Data from a 12-Bit Analog-to-Digital Converter - 
This example shows how you can use the parallel I/O port to receive 
analog data of higher resolution than 8 bits and also use one of the 
port's timers to control the sample rate instead of supplying an 
external clock. 
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Figure 3-4: Receiving Data from a 12-Bit Analog-to-Digital Converter 


Configuration 


Figure 3-4 shows the external connections between the parallel I/0 
port and the 12-bit A/D converter. The listing of the YK handler 
prefix file that follows shows you how to specify this configuration. 
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-MCALL YKCI$ 


YKCIS sBeginning of Prefix File 


;Port A Setup 


Port A is an input port with 
strobed handshake. 


YKCPS CHAN=A, PTYPE=YKSINP, HSH=YKSSTR 


me me 


;Port B Setup 


YKCPS CHAN=B, PTYPE=YKSBIT, PLNK=TRUE Port B is a bit input port 


linked to Port A. 


me me 


;Port C. Setup 


YKCPS CHAN=C, PTYPE=YKSBIT, OUT=<YKSB3+YKSB@> ; Port C is a bit port with 
; bits @ and 3 set for output. 


;Timer Setup 
YKCTS TNUM=3, TEXTO=YES, TOUT=YKSTPL ; Timer 3 enabled for pulsed output. 


YKCES End of Prefix File 


=e 


MicroPower/Pascal Program Fragment 


Programming for the 12-bit A/D input is similar to that shown in the 
portion of the previous example that received 8-bit A/D values. You 
still have to provide the YK handler with multiple buffers so it can 
continue to receive input after it returns a buffer. In addition, a 
SET TIMER command must be sent to provide the clock output that 
triggers the A/D device. 


3.4.1.4 Using the Counter-Timers to Count External Pulses - This 
example shows how to create an external pulse counter that is 
unaffected by timing delays caused by software. Timing accuracy is 
guaranteed by setting up the hardware to stop the counting process at 
the instant it presents an interrupt request to the processor. 


The example uses timer 3 to time the counting interval and timer 1 to 


count the number of pulses. Timer 3 causes the software to be 
signaled and stops timer 1 from counting by shutting off its gate 
input. That way, when the software reads the number of counts from 


timer 1 it will be exact. As explained in the hardware documentation, 
timer 3 must be set up to have a one-shot output and run in the 
noncontinuous mode to accomplish this. To expand this into a 32-bit 
counter, you can link timer 2 to timer l. 
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Figure 3-5: 


Configuration 


Figure 3-5 shows the external connections 
port and the application environment. 


Parallel /O Counter—Timer 


Input Signal 


Timer 3 Output 
(internal connection through Port C) 


Timer 1 Gate Input 
(internal connection through Port B) 


User's Application 








Using the Counter-Timers to Count External Events 


between the parallel I/0 


The listing of the YK handler 


prefix file that follows shows you how to specify this configuration. 


- MCALL 


YKCIS 


7;Port B Setup 


YKCP$ CHAN=B, 


7Port C Setup 


YKCPS CHANE=C, 


;Timer Setup 


YKCTS TNUM=1, 
YKCTS TNUM=1, 


YKCTS TNUM=3, 


YKCES 


YKCIS 


PTYPE=YKSBIT 


PTYPE=YKSBIT, OUT=1 


TEXTG=YES 
TEXTC=YES 


TEXTO=YES, TOUT=YKST1S 


=e =e 


=e 


™e we BO ME NO 


=e 


-Beginning of Prefix File 


timer 1's gate input via bit 7 


Timer 3's output via bit @. 


Enable timer 1's gate input. 
Enable timer 1's count input 
via port B bit 5. 

Enable timer 3's output 

in one-shot mode. 


End of Prefix File. 
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MicroPower/Pascal Program Fragment 


The following MicroPower/Pascal program fragment illustrates how a 
program can use the YK handler to count pulses. 


[ SYSTEM (MICROPOWER) J PROGRAM C3EX3 ; 


{ SNOLIST} 

include 'DEF:IODEF.PAS' 
include 'DEF:YKINC.PAS' 
{SLIST} 


CONST 
COUNT_INT = 106 ; { define the counting interval } 


VAR 

Status code returned from YK } 
Dummy reply descriptor } 

Actual reply descriptor } 

Reply packet from the YK handler} 
Number of counts during interval} 


YK_IO0 STATUS : IOSSTATUS ; 

NIL REPLY DESC : STRUCTURE_DESC ; 
REPLY DESC : STRUCTURE DESC ; 
REPLY _PKT : YK_REPLY ; 

COUNTS : UNSIGNED ; 


hn ay pn chen rn 


BEGIN 
NIL REPLY DESC .ID := NO SEM ; 


IF CREATE QUEUE SEMAPHORE (DESC := REPLY DESC ) THEN 
BEGIN 
{ First set the counter to zero } 
YK_10 STATUS := YK SET TIMER 
( TIMER_NUM := TIMER1 , 

TIMER VALUE 2= O , 
MODE := [ init constant, trigger ] , 
REPLY := ADDRESS (NIL REPLY DESC) yi 


{ Now start the time interval, and the counter } 
YK IO STATUS := YK SET TIMER 
 : ~  —s { TIMER_NUM := TIMER 3 , 
TIMER VALUE := COUNT _INT , 
MODE := [ init _constant, trigger ] 
REPLY := ADDRESS ( REPLY DESC ) ) 3 


- 


{ Wait for the time interval to expire } 


RECEIVE ( VAL_DATA := REPLY_PKT, 
VAL_LENGTH := SIZE (YK_REPLY) , 
DESC := REPLY_DESC ) ; 


{ Read the number of pulses, and put the answer in COUNTS } 
YK_IO0 STATUS := YK_READ TIMER ( timer_num := TIMER_1 , 
pt_time := ADDRESS ( COUNTS ) ) 


ue 


END : 
END. 


3.4.1.5 Using the Counter-Timers to Supply External Pulses - This 
example shows how to set up a timer to generate external pulses but 
not reply at the completion of any of the cycles. This configuration 
is useful when you need an output waveform that is independent from 
the application software time base. 
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Figure 3-6: Using the Counter-Timers to Supply External Pulses 


Output Waveform 


Configuration 

Figure 3-6 shows the external connections between the parallel I/0 

port and the application environment. The listing of the YK handler 

prefix file that follows shows you how to specify this configuration. 
-MCALL YKCIS 


YKCIS 


=e 


Beginning of Prefix File 


,Port C Setup 


YKCP$ CHAN=C, PTYPE=YKSBIT, OUT=1 ; Timer 3's output via bit @ 


;Timer Setup 

YKCTS TNUM=3, TEXTO=YES Enable timer 3's output and 
leave it in the default (square 
wave mode). . 


me MO MO 


YKCES ; End of Prefix File 


MicroPower/Pascal Program Fragment 


The following MicroPower/Pascal program fragment illustrates how a 
program can use the YK device handler to generate a 
software-independent time base. é 


The SINCLUDE commands in the following example refer to the RT-11 
logical device LB:. If your host environment is RSX-11 or VMS, 


substitute the appropriate logical device. Refer to the 
MicroPower/Pascal Installation Guide for this information. 
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{ SYSTEM(MICROPOWER) ] PROGRAM C3EX4 ; 


{ SNOLIST} 

include 'LB:IODEF' { get the INCLUDE file for the common} 
{ 1/0 definitions} 

include 'LB:YKINC' get the INCLUDE file for the 


device handler interface routines} 


{SLIST} 
CONST 
COUNT_INT = 160 ; { define the counting interval } 
VAR 
YK IO STATUS : IOSSTATUS ; { Status code returned from YK } 


NIL REPLY DESC : STRUCTURE DESC ; { Dummy reply descriptor } 
BEGIN 


NIL_REPLY DESC .ID := NO _SEM ; 


BEGIN 
{ First set the counter to the initial value and trigger it. } 
YK_IO0 STATUS := YK _SET TIMER 
( TIMER_NUM := TIMER 3 , 
TIMER VALUE := COUNT INIT , 
MODE <= [ init_constant, trigger, continuous ] , 
REPLY := NIL_REPLY DESC )3 


END ; 
END. 


3.4.2 Using the Asynchronous I/O (XL) Device Handler 


The KXT11-C XL device handler supports asynchronous I/O operations on 
devices connected to any of the three serial I/O ports on the KXT11-C 
peripheral processor. This handler is similar to the mnon-KXT11-C. XL 
handler described in the MicroPower/Pascal Runtime Services Manual 
except it also supports the multiprotocol communication controller 
(7281 chip) on the KXT11-C. This allows the KXT11-C to concurrently 
service the three serial ports SLU1, SLU2 channel A, and SLU2_ channel 
B. 


The first serial I/O port on the KXT11-C (SLU1) is a standard DL 
asynchronous’ receive/transmit (DLART) device. The second port (SLU2 
channel A) provides all the features of a DLV11-E, including modem 
control, but is a distinct hardware type. The third port (SLU2 
channel B) provides all the features of a standard DLART device but is 
a different hardware device. When you use SLU2 channel A or channel 
B, you must specify one of the following TYP parameters for the LINDFS$ 
macro in. the handler's prefix file. 


TYP Description of Type 


TTSDM Multiprotocol channel using no modem control 
TTSDMP Multiprotocol channel using partial modem control 


TTSDMM Multiprotocol channel using full modem control (SLU2 
channel A only) 


-A description of the modem control options can be found in the 
MicroPower/Pascal System Users Guide. 
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3.4.3 Using the Synchronous I/O (XS) Device Handler 


The XS device handler supports synchronous serial I/O via the KxT11-C 
multiprotocol communication controller (7201 chip) SLU2 channel A, 
allowing you to establish an elementary bit-oriented communication 
channel. The handler performs the following functions of bit-oriented 
communication procedures. 


Synchronization (flag detection) 

Transparency (bit stuffing) 

Invalid frame detection 

Frame abortion detection 

Frame check sequence (FCS) checking/calculation 


The handler can be used by usSer-written software aS a component in 
performing such bit-oriented communication procedures as CCITT X.25, 
ISO HDLC, IBM SDLC, ANSI ADCCP, and others. However, the XS handler 
does not, in itself, completely perform any of these procedures. The 
XS handler provides no explicit modem control, although the 
line-enable and line-disable services control modem signals as 
necessary to activate and deactivate a modem. 


3.4.3.1 XS Device Handler Functions - The XS handler provides basic 
ISO HDLC style framing and error detection. 


FLAG Data from user buffer FCS FLAG 


Data sent by the handler has the FCS (frame check sequence) appended 
to form a frame. If any errors are detected as the handler sends the 
frame it is aborted and resent. Frames received by the handler use 
the embedded FCS to verify the frame; the FCS is then removed. If FCS 
checking indicates the frame was received in error or if the frame was 
aborted or invalid, the frame is discarded with no indication to the 
user. Otherwise the data is returned to the user. 


The source files of this handler are provided on the MicroPower/Pascal 
distribution kit to assist you in writing your own handler for the 
multiprotocol controller. 


3.4.3.2 Functions Performed by User Software - Because frames 
received in error are discarded, user software must be able to 
determine when a frame has not been received. A sequence 
number/timeout scheme can be used for this purpose: A sequence number 
is included in the data portion of each frame. As the user software 
receives each frame it responds by sending another frame acknowledging 
receipt with the first frame's sequence number. If, after a period of 
time, the originator of the first frame determines that no 
acknowledgment has been received, it resends that frame. 


For further information about the techniques of data communication, 
refer to Technical Aspects of Data Communication, John E. McNamara, 
DIGITAL Press, 1982, or a good book of your choice on data 
communication principles. 
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3.4.3.3 Accessing the XS Handler - 
Configuration 


The XS handler makes no assumptions about the configuration of the 
multiprotocol communication controller, other than assuming’ the 
interrupts have been enabled for the device. Refer to the KXTI11-CA 


° s aT a tan ee 
User's Guide hardware reference manual for complete information on 
this device. 


MicroPower/Pascal Program Fragment 


This example shows you how to access the XS handler only; it is not an 
example of data communication protocol. The handler is configured 
with the standard XSPFXK.PAS prefix file. 


The INCLUDE command in the following. example refers to the RT-11 
logical device LB:. If your host environment is RSX-11 or VMS, 
substitute the appropriate logical device. Refer to the 
MicroPower/Pascal Installation Guide for this information. 


program exampl; - { xS handler use -- program fragment } 


{Snolist} 
include 'LB:iopkts.pas' 
{$list} 


const 
get_frame = IFSREAD PHYSICAL; 
send_frame = IFSWRITE PHYSICAL; 
enable line = IFSDEV_DEP 61; 
disable line = IFSDEV_DEP 82; 
kill requests = IFSDEV_DEP 93; 
buf size = 33 ; { size of buffers } 


start_pattern 


'123456789@ABCDEFGHIJKLMNOPQRSTUW!' ; { beginning pattern } 


PACKET LENGTH 22; 
type 


buffer = record 


num : unsigned; 
dat : packed array [l..buf_size] of CHAR ; 
end; 
var 


I: integer; 
garbage : BOOLEAN; 


SDB for my reply queue } 
SDB for the handler } 


reply queve : structure desc; 
handler queue : structure desc; 


loon aon) 


read request, write request, 
enable request, disable request : IOSREQ_PKT; 


command reply : IOS$REPLY_PKT; 

write buffer, read_buffer : buffer; 
begin 
{* 


* First initialize things 


=} 
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garbage := create_queue semaphore (NAME := 'RPLYQ ' ) ; 
init_structure_desc ( desc := reply queue , name := 'RPLYQ ' ) ; 
init_structure desc ( desc := handler_queue , name := 'SXSA ' ) ; 
WITH enable request DO BEGIN 

oper := enable line; 

reply sem := reply queue.ID ; 
END ; 


WITH write request DO BEGIN 
oper := send_frame ; 
reply sem := reply queue.ID ; 
END ; 


WITH read_request DO BEGIN 
oper := get_frame ; 
reply sem := reply queue.ID ; 
END ; : 


write buffer.dat := start_pattern ; 


SEND ( 
VAL_DATA := enable request, 
VAL_LENGTH := PACKET LENGTH, 
DESC := handler_queue ) ; 


RECEIVE ( 
VAL_DATA := command reply, 
VAL_LENGTH := PACKET LENGTH, 
DESC := reply queue ) ; 
{* 
* Now loop here, sending a read and write request, and wait for replies. 
2 
WHILE TRUE DO BEGIN 


SEND ( 
VAL_DATA := read_request, 
VAL LENGTH := PACKET LENGTH, 
REF DATA := read_buffer, 
REF_LENGTH := SIZE ( buffer ) , 
DESC := handler queue ) ; 


write _buffer.num := write _request.sequence; 


SEND ( 
VAL DATA := write request, 
VAL_LENGTH := PACKET LENGTH, 
REF DATA := write buffer, 
REF_LENGTH s= SIZE ( buffer ) , 
DESC := handler queue ) ; 


FOR I. := 1 TO 2 DO RECEIVE ( 
VAL_DATA := command_reply, 
VAL_LENGTH := PACKET LENGTH, 
DESC := reply queue ) ; 


END; 
END. 


3.4.4 Using the TU58 DECtape II (DD) Device Handler 


The DD device handler is similar to the standard MicroPower/Pascal 
arbiter DD handler except it includes support for SLU2 channel A and 
SLU2 channel B (multiprotocol communication controller) on the 
KXT11-C. This lets you connect a TU58 DECtape II subsystem to any of 
the serial lines on the KXT11-C. 
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The DD device handler supports logical and physical I/O operations on 
a TU58 cartridge tape subsystem. The handler also supports 
read-with-increased-threshold and write-verify options and reports the 
storage capacity of the device in terms of logical blocks. 


Requests for logical read/write functions specify the initial tape 
address in terms of a 512-byte logical block. Logical block numbers 
range from 8 to 5ll. 


Requests for physical read/write functions specify the initial tape 
address in terms of a 128-byte physical record (that is, tape 
positioning is performed in special address mode). Physical record 
numbers range from @ to 2047. Multirecord transfers exceeding 128 
bytes read from or write to physically sequential records on the tape. 


The functions provided by the handler are described in further detail 
in the MicroPower/Pascal Runtime Services Manual. 


The KXT11-C DD handler is in the KXT11-C handler library, DRVK.OBJ. 
To use the KXT11-C DD handler, you must edit its prefix file, 
DDPFXK.MAC, and then use the prefix file to build the kxXT11-C DD 
handler into your application software. Software configuration 
Procedures are described in the MicroPower/Pascal-RT-11 System User's 
Guide. In the TYPRM parameter of the CTFCFS macro you must specify 
the terminal type and bit rate of the KXT11-C line you intend to use. 
The type parameter can be one of the TTSDMx parameters described in 
Section 3.4.2. , 


3.4.5 Using the QD (DMA Transfer Controller) Handler 


The QD device handler provides a standard device handler interface to 
the two-channel DMA transfer controller (DTC) on the KXT11-C. The QD 
handler moves data from place to place without the assistance of the 
CPU. Any memory location can serve as a_ source or destination 
including I/O device registers (with certain restrictions). However, 
at least one location, source or destination, must be local to the 
KXT11-C. 


Your programs can access the QD handler from MicroPower/Pascal or 
-.MACRO-11 routines by using the standard primitive I/O requests or the 
MicroPower/Pascal device-handler interface routines listed below. All 
examples shown in this section use these routines. 


SDMA_TRANSFER -- Performs DMA transfer 
SDMA SEARCH -~ Performs DMA search 
SDMA_SEARCH_ TRANSFER -- Performs transfer while searching 


SDMA_ALLOCATE -~ Allocates DMA channel 
SDMA _DEALLOC -~ Deallocates DMA channel 
SDMA GET STATUS -- Gets status of DMA unit 
Chapter 4 and Appendix H of the MicroPower/Pascal Runtime Services 


Manual provide detailed information about the MACRO-11l and 
MicroPower/Pascal interface to the QD device handler. 
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You can use the QD handler and its associated interface routines to: 
e Transfer data to and from Q-BUS memory. 
® Transfer data to and from local memory. 
e Search for data. 
e Transfer to and from local I/O devices. 
e Access the Q-BUS I/O page. 


e Assure access to a DMA Channel. 


3.4.5.1 Transferring Between Local Memory and Q-BUS Memory - The QD 
handler can transfer data between KXT11-C and system memory. The 
following program fragment shows such a transfer. 


CONST 
BUFSIZE = %0'2600'; 
QBUSBUF = DMASADDRESS ( %0'70008', %0'2', DMASNOIO, DMASWAIT_@, DMASUP, 
- DMASNOWFR, DMASNOBYTE, DMASQBUS ); 
VAR 


bufl : PACKED ARRAY [1..BUFSIZE] OF BYTE RANGE; 
address 1 : DMASADDRESS; 


BEGIN 
address 1 := DMASNORM_IBUS ADDRESS; 
address _1l.low := (ADDRESS (BUF1))::UNSIGNED; 


SDMA_TRANSFER ( 
UNIT := un, 

SOURCE := address l, 
DEST := QBUSBUF, ~ 
COUNT := BUFSIZE ) 


transfer... } 

on this unit } 

from my local buffer } 
to the Q-BUS buffer } 
this much } 


3.4.5.2 Transferring Data Within Local Memory - The QD handler can 
transfer data within KXT11-C memory. The calls are similar to the 
previous example except the destination address is replaced by a local 
address. In the following example fragment, some of the addressing 
options are also used. This transfer will invert a local (to the 
KXT11-C) buffer end for end, in byte mode, which will have the effect 
of reversing the byte order. 


VAR 
bufl, buf2 : PACKED ARRAY[1..BUFSIZE] OF BYTE; 
address 1, address 2 : DMASADDRESS; 


BEGIN 
address 1 := DMASNORM IBUS ADDRESS; 
address 1l.low := (ADDRESS (BUF1)) ::UNSIGNED; 
address 2 := DMASNORM IBUS ADDRESS; 
address 2.low := (ADDRESS (BUF2) )::UNSIGNED+BUFSIZE-1; 
address 2.ws := DMASWAIT 4; 
address 2.inc := DMASDOWN; 
address 2.bm := DMASBYTE; 


SDMA_TRANSFER ( 
UNIT := un, 

SOURCE := address l, 
DEST := address 2, — 
COUNT := BUFSIZE ) 


transfer... } 

on this unit } 

from my local buffer } 

to the other local buffer } 
this much } 


PIN CPN CPN CPN CON 
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3.4.5.3 Using the Search Option - The QD handler supports two search 
options, with or without data transfer. 


3.4.5.3.1 Searching with Transfer - This option can transfer 
variable-length messages. The search looks for an end-of-message 
character and terminates the transfer at that point. The following 
example shows how to copy variable-length messages. 


VAR 
bufl, buf2 : PACKED ARRAY[1..BUFSIZE] OF BYTE; 
address 1, address 2 : DMASADDRESS; 


BEGIN 
address 1 := DMASNORM IBUS ADDRESS; 
address 1.low := (ADDRESS (BUF1) ) : :UNSIGNED; 
address 2 := DMASNORM_IBUS ADDRESS; 
address 2.low := (ADDRESS (BUF2))::UNSIGNED; 


transfer... } 

on this unit } 

from my local buffer } 

to the other local buffer } 
looking for a @... } 

in the high byte } 

this much } 


k 3:= SDMA_SEARCH_TRANSFER ( 
UNIT <:= un, 
SOURCE := address l, 
DEST := address 2, — 
VAL := @, 
MASK := %0!377', 
COUNT := BUFSIZE ); 


ON A AN A AN AN 


3.4.5.3.2 Searching Without Transfer - This option allows a program 
to determine the length of a buffer of data by searching for an 
end-buffer character. Searching can also be used to poll a location. 


3.4.5.4 Transferring to and from Local I/O Devices - The QD handler 
can transfer data to and from KXT11-C local I/O devices without the 
involvement of the processor. The YK handler supports interaction 
with the QD handler. The SLU2 serial lines can be accessed directly 
from user-written software in DMA mode, but DIGITAL-supplied software 
does not support DMA access to the serial. ports. 


3.4.5.4.1 Parallel I/0 Using DMA - The YK and QD handlers in 
conjunction can perform DMA transfers to and from the parallel 1/0 
port. The following example shows a sequence of commands’ that 
transfer data from the parallel port to local memory on the KXT11-C. 
The example assumes the port A request line is connected to DMA 
channel 1 and that channel is allocated for use by this process. 


The @INCLUDE commands in the following example contain references to 
RT-11 logical device LB:. If your host environment is RSX-11 or VMS, 
substitute the appropriate logical device. Refer to the 
MicroPower/Pascal Installation Guide for this information. 
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MicroPower/Pascal Program Fragment 


SINCLUDE LB: IODEF.PAS 
SINCLUDE LB: QDINC.PAS 
SINCLUDE LB: YKINC.PAS 


VAR 
YK_REQ : YK PORT RQST ; { Request Packet for YK handler } 
YK_RPLY_ DESC : SEMAPHORE_DESC ; { Sem for YK reply - assumed 
to be already initialized } 


FUNCTION PORT A DMA_INPUT ( 
YK_DMA_ADR : DMASADDRESS ; { port address in DMA format } 
BUF DMA ADR : DMASADDRESS ; { buffer address in DMA format } 
DATA_LENGTH : UNSIGNED { length of data transfer } 
) 3 DMASBYTE COUNT ; { function returns number of 
. bytes actually transferred } 


BEGIN 

WITH YK REQ DO 
BEGIN 
oper := DMA_READ 
funct_mods := [] ; 
ind_mods := [ FISSIMPLE_REPLY ] ; 
unit_num := PORTA ; 
reply sem := yk _rply desc .id ; 
END ; 


oe eo 


SEND ( NAME := 'SYKA ', 
VAL_DATA := YK REQ , 
VAL LENGTH := SIZE (YK PORT RQST) ) ; 


WAIT ( DESC := YK_RPLY DESC ) ; 


PORT _A_DMA_INPUT := SDMA_TRANSFER ( SOURCE := YK_DMA_ADR , 
DEST := BUF_DMA_ADR , 
COUNT := DATA_LENGTH , 
UNIT := 1) ; 


YK_REQ . oper := DMA_COMPLETE ; 


SEND ( NAME := 'SYKA ' , 
VAL_DATA := YK_REQ , 
VAL_LENGTH := SIZE (YK_PORT_RQST) ) ; 


WAIT ( DESC := YK _RPLY DESC ) ; 


END. ; 


3.4.5.4.2 Reading and Writing Data from/to Serial Line Ports - You 
can use the DMA handler to read data from or write data to the 
serial-line ports SLU2 channel A and SLU2 channel B. This operation 
must be done by user-supplied software that sends requests to the DMA 
handler since the XL and XS handlers do not support the operation. 
You can read or write characters by using the request line hardware on 
either channel of SLU2. 
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3.4.5.5 Accessing the Q-BUS I/O Page - The QD handler can be used to 
access the Q-BUS I/0 page, allowing I/O processing directly by the 
KXT11-C, but you cannot connect the Q-BUS DMA request line to the 
KXT11-C DMA device (which would notify the DMA device that the Q-BUS 
device is ready to be read or written). However, the QD handler can 
be used with a Q-BUS device if the device has a silo that will accept 
new data each time it is written/read. 


3.4.5.6 Assuring Access to a DMA Channel - To assure that a DMA 
channel is available when you need it, you can dedicate access to 
either or both channels to a given process with the DMA _ALLOCATE 
command. This feature can be used when a transfer must occur within a 
specific time period following an event. You dedicate the DMA channel 
before the event so you are assured your transfer request will not be 
held up by another transfer in progress. 


3.4.6 Using the KX (Arbiter-Resident Two-Port RAM) Handler 


The KX handler performs the arbiter (master) portion of the KX/KK 
protocol described in Appendix A. It passes data between the arbiter 
CPU and up to 14 KXT11-C peripheral processors running on the Q-BUS. 
The handler communicates with the KXT11-C through the command and 
status registers of data channel @ and data channel 1 of the two-port 
RAM (TPR). It operates in conjunction with the KK handler described 
in Section 3.4.7. 


Each unit is associated with a unique interrupt to the handler to 
permit fast communication. The controller IDs, unit numbers, 
associated register base address, and default interrupt vectors for 
each system ID switch position are shown in Appendix C. The KX 
handler is in DRVU.OBJ and DRVM.OBJ, not DRVK.OBJ. 


The run-time hardware support library (RHSLIB.OBJ) includes’ two 
routines, KX WRITE DATA and KX READ DATA, that can be used to send and 
receive data via the KX/KK handlers to and from the KXT11-C. These 
routines and associated data structures are defined by the INCLUDE 
file KXINC.PAS. 


Refer to Section 3.5 for examples of the use of the KX handler in 
peripheral processing applications. 


3.4.7 Using the KK (KXT11-C-Resident Two-Port RAM) Handler 


The KK handler performs the slave portion of the KX/KK protocol 
described in Appendix A, and operates in conjunction with the KX 
handler described in Section 3.4.6. The prefix file KKPFXK.PAS 
configures data channel @ (4-byte data area) as KK unit 8 and data 
channel 1 (12-byte data area) as KK unit l. 


The run-time hardware support library (RHSLIB.OBJ) includes two device 
handler interface routines, KK WRITE _DATA and KK READ DATA, that can 
be used to send and receive data via the KK/KX handlers to and _ from 
the arbiter. These routines and associated data structures are 
defined by the INCLUDE file KKINC.PAS,. 


Refer to Section 3.5 for examples of the use of the KK handler in 
peripheral processing applications. 
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3.5 PROGRAMMING THE KXT11-C PERIPHERAL PROCESSOR INTERFACE 


MicroPower/Pascal provides the following tools to assist you in 
programming your peripheral processing application. 


e KX and KK device handlers. They provide a_ two-channel 
communication path from the arbiter to the KXT11-C and can be 


used to pass data or commands to and from the KxXT11-C under 
control of the arbiter program. 


@e QD device handler. It provides a two-channel DMA path that 
can move interfacing data at a high rate without processor 
intervention. 


e Device handler interface routines and associated *%INCLUDE 
files that simplify the use of the KK, KX and QD device 
handlers. 


3.5.1 Interface Considerations 


A peripheral processing application consists of several separate 
processes that control the peripheral processor and send, receive, and 
process data associated with it. Some of these processes reside in 
the arbiter processor and some reside in one or more XKxXT11-C 
peripheral processors. MicroPower/Pascal provides low-level 
interconnections between these processes in the form of semaphores and 
ring buffers for communication between processes running on a_= single 
processor, and KX, KK, and QD handlers for communication between 
processes running on separate processors. An application using the 
handlers for communication must contain the following additional 
protocols or interfacing. 


@e Commands Necessary to Control the KXT11-C Application -- If 
you need control information to start, stop, or interrupt the 
KXT11-C application from the arbiter, or if you need to 
differentiate between report information and alarm information 
in messages received from the KXT11-C, you can encode the 
commands in a message format. For example, you can assign 
commands as numbers in the first byte of the message followed 
by five bytes containing the address of the buffer to copy the 
data into and two bytes containing the length of the buffer. 


e Message Passing Mechanisms -- Large blocks of data or 
frequently sent data are more efficiently passed with the DTC. 
To initiate transfer of the data you can pass the address and 
length of the buffer in a command message sent by the KX/KK 
handlers, then instruct the QD handler to transfer it. 
Alternatively you can choose a fixed buffer location and a 
flag location to test (using the DTC) to determine when to 
write the data. The application in the KXT1L1-C must inform 
the arbiter application each time data is written or read. A 
message through the TPR is the most likely method. 


For shorter or infrequently issued messages, you can send just 
the data aS a message using the KX/KK handlers. 


e Arbiter Management of Errors from the KXT11-C Application -- 
An error message should inform the arbiter application of 
error or alarm conditions, and appropriate procedures’ should 
deal with them. Such management is required when the KXT11-C 
application cannot access some memory location using the DTC. 
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e Protection of Shared Memory Areas -- Shared themory areas in 
the Q-BUS system or the kKXT11-C should be protected from 
simultaneous access. Semaphores will suffice for some areas, 
but others (for example, buffers that can be used and modified 
by KXT11-C and arbiter applications) will require semaphores 
and control messages. 


If you have two processes in one KXT11-C using the KX/KK communication 
path, you can dedicate one channel to each process. The second 
channel uses more of the two-port RAM (six words at a time instead of 
two) to pass messages and thus is faster for messages greater than two 
words in length. 


If you have more than two processes contending for use of the KX/KK 
communication path, you must write two message switching processes 
that will add a destination address to the message to select the 
receiving process on the receiving end, with one switching process at 
each end of the path (the KXT11-C end and the arbiter end). Each 
Switching process should decode the address, strip it from the 
message, and pass the message on to the receiving process. 


3.5.2 KK/KX Interface Example 


An example peripheral processor application is in the 
MicroPower/Pascal kit. Its installation and operation is documented 
in Appendix A of the MicroPower/Pascal Installation Guide. The 
following KK/KX interface example draws from this example application 
and uses sections of the MicroPower/Pascal source files IOPVFY.PAS and 
ARBVFY.PAS. 


The example peripheral processor application is a simulation of an 
ideal ball bouncing within an ideal rectangular box. It isa 
peripheral processor application because half of the box is managed by 
the arbiter program and the other half is managed by the KXT11-C. As 
the ball leaves the right edge of the screen in the arbiter controlled 


half, it appears at the left edge of the screen in the KXT11-C 
controlled half. 


The ball is modeled in the programs as a vector containing its current 
position and velocity. This is shown by the following 
MicroPower/Pascal data structures. 


col 
row 


B..79; 
G..23; 


vector = record 


X,Y : real; { X and Y components } 
end; 


screen_pos = record 
C.# eCols 

ro: row; 

end; 


Ball = record 
: vector; Old position } 

Position } 

Velocity } 

Position in screen units } 


Old position in screen units } 


: vector; 

vo: vector; 

sp : screen_pos; 
osp : screen_pos; 


PRONE EN CAS 
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The old position and the screen positions are included for ease of 
moving the ball around the’ screen. 


When the ball is passed from one system to another the current ball 
record must be transmitted. This is done with a message like this: 


message = record 
case m_type : char of { Message type } 
"b": (b:Ball); 
end; 


The record field m_type distinguishes. between different types of 
messages, of which only one is defined, the m_type “b" for Ball. This 
field can be used to define "i" for Initialize, "a" for Alarm, and so 
on. 


Now, it is a simple matter of repeatedly moving the ball one v 
(velocity) from p (the current position) during each time unit and 
checking to see if it hit a wall or got passed to the other side, as 
follows. 


Fly(b); 

if (b.p.x < LEFT) then Pass(b); 

if (b.p.x > RIGHT) then Bounce(b.p.x,RIGHT,b.v.x); 
if (b.p.y < TOP) then Bounce(b.p.y,TOP,b.v.y); 

if (b.p.y > BOTTOM) then Bounce(b.p.y,BOTTOM,b.v.y) ; 
Show(b); 


Here, Fly moves the ball one v from p, Bounce performs whatever is 
needed to bounce the ball off one of the walls, Show displays the ball 
on the screen, and Pass takes the current ball vector and passes it to 
the other side. In this application, once the ball is passed to the 
other side, there is nothing else for this side to do but wait for the 
ball to come bouncing back again, and so Pass, shown below, just waits 
for this to happen. (Your application may very well have other 
processes performing other tasks.) 


procedure Pass(var b:Ball); 
var 
m : message; 
garbage : ioSstatus; 
garbage2 : unsigned; 


begin 
m.m_type := "b"; 
m.b := b; 


garbage := KK_write data(m,size(m) ,garbage2); 

garbage := KK read data(m,size(m) ,garbage2) ; 
b := m.b; 

end; 


3.5.3 Determining Physical Addresses 


When using the QD handler to move data blocks to and from arbiter 
memory, you should provide a physical address for a buffer in the 
arbiter memory. This is done by declaring a process as handler-mapped 
and using the higher order 3 bits of the buffer address as an index 
into the memory management unit (MMU) registers. Using the PAR (page 
address register) of the MMU and the buffer address, you can calculate 
a physical address. 
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3.6 DEBUGGING A KXT11-C APPLICATION 


This section describes the aspects of program debugging that are 
unique to KXT11-C applications. 


3.6.1 Setting up PASDBG 


The following list contains general requirements for setting up the 
KXT11-C for use with the PASDBG debugger. 


1. Configure memory as follows. 


For RAM systems, configure memory just as it will be in the 
final application (Section 3.3.1.1). 


For ROM systems, configure memory just as it will be in the 
final application (Section 3.3.1.1, steps 1 to 4) but install 
the equivalent-size RAM in the user sockets in place of ROM. 
Set the memory map selection jumpers appropriately for those 
RAMs (refer to the KXT11-CA User's Guide hardware reference 
manual). 


When you specify the MEMORY macro parameter TYPE=ROM in the 
kernel configuration file, the application's pure code and 
pure data is built into the ROM (or what will eventually be 
ROM) address_ space. PASDBG can then load the application 
into the KXT11-C because the ROM has been replaced with RAM. 
Keeping the ROM portions of the application separate from the 
RAM portions helps track the size of each while the program 
is growing and facilitates your use of a logic analyzer to 
detect corrupt areas of ROM. 


2. Build the debugger service module (DSM) into your application 
by specifying DEBUG = YES in the kernel configuration file. 


3. Build in debugging symbols by using the /D option in the 
MERGE, RELOC and MIB steps of the application build process. 
This is performed automatically by the MPBLD procedure when 
you build a configuration that includes debugging. 


4. Set the boot/self-test switch to position 4. 


5. Set the baud for SLU1 using the baud jumpers on the KxT11-C 
circuit board. Do not use the autobaud feature. 


6. Install the SLU1 break-enable jumper on the KXT11-C circuit 
board. 


7. Once PASDBG and the target KXTI11-C are running and before - 
loading and running your application, use PASDBG in ODT mode 
to open location 175992. Then set bit 4 (enter console ODT 
on halt) to 1. This prevents the KXT11-C from trapping 
through vector 19 if a HLT instruction is executed. 


3.6.2 Test System Configuration 


You should develop a program specifically to test the operation of 
your peripheral processor application before integrating with the 
arbiter section of the application. The test program can be run under 
RSX-11, RT-11 or MicroPower/Pascal. If you develop the arbiter test 
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program under RT-11 or RSX-1l, you can use all the program development 
and testing aids that are available with these operating systems to 
facilitate running your test program and examining the results (for 
example, interactive terminal interface, indirect command files, file 
management and compare utilities, and so on). The test program should 
pass commands to the application in the KXT11-C and verify that the 
correct results are returned. 


3.6.3 Debugging with an RT-11 or RSX-11 Arbiter Test Program 


Develop a test program that runs under RT-11 or RSX-1l. This program 
should pass appropriate commands and messages to the kKxT11-C 
application and verify the results that are returned. 


Perform the following steps. 


1. Connect the host to the KXT11-C console port in the same way 
you connect a stand-alone system. 


2. Load the application into the KXTI1-C with PASDBG's' LOAD 
command, then start execution with the GO command. 


3. Start your arbiter test program and begin testing. 


You can use PASDBG to set breakpoints and watchpoints as in normal 
debugging operations. You can also use the KK handler debugging 
features described in Section 3.6.6. You can use the KUI utility 
program's TRAP command to test trap handling routines in the KXT11-C 
application. 


3.6.4 Debugging with a MicroPower/Pascal Arbiter-Resident Test 
Program 


To debug a KXT11-C application using a MicroPower/Pascal 
arbiter-resident test program, you use PASDBG to interact with the 
test program in the arbiter and the application program in the 
KXT11-cC. The methods for accomplishing this are the same as those 
described in Section 32665 for debugging multiple-processor 
MicroPower/Pascal applications. 


3.6.5 Debugging Multiple-Processor MicroPower/Pascal Applications 
Simultaneously 


If you want to access more than one processor with PASDBG to determine 
the cause of a malfunction in a peripheral processing SEDER Aron! you 
can use one of two methods. 


One method has a separate PASDBG host system process and terminal for 
each processor in the target system. This is the most convenient way 
of debugging in the VMS and RSX-1l host environments. The other 
method, using a single PASDBG host system process, switches the 
communication line that PASDBG uses from processor to processor as 
required. With either method you attach a serial line from the host 
to the console port of each target system. 
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To switch back and forth between systems with PASDBG, you exit PASDBG, 
select the serial line connected to the desired processor, and restart 
PASDBG. You can simplify this by creating indirect command files or 
user-defined commands. 


3.6.5.1 Setting up PASDBG as a Single Host Process - To transfer 
control back and forth between processors, you should create indirect 
command files or user-defined DCL commands that will load the 
appropriate handler and start PASDBG. Examples of command files to 
configure PASDBG in RT-11, RSX-11 or VMS are given in the following 
examples. 


RT-11 Host Systems 


~UNLOAD TD 

-SET TD CSR aaaaaa 
~SET TD VECTOR vvv 
~LOAD TD 


RSX-11 Host Systems 


>DEA TD: 
>ALL TTnn:=TD 


VMS Host Systems 
SDEFINE TD: fTTcn: 


The peripheral processor verification procedure in the 
MicroPower/Pascal kit includes a command file, PPVFY, which generates 
two other command files that switch PASDBG between the arbiter and 
KXT11-C (refer to the applicable MicroPower/Pascal installation 
guide). Using these files as models, you can create your own command 
files to switch PASDBG between multiple KXT11-C processors. 


3.6.5.2 Loading and Starting Target Processors - You must use _ the 
PASDBG LOAD command to load each target processor so that the DSM is 
properly initialized. You cannot use the KXT LOAD procedure or the 
KUI utility program to load a KXT11-C from the arbiter processor if 
you wish to debug it with PASDBG. 


Once a target is loaded, you can set breakpoints or watchpoints 
(Section 3.6.5.3). Thereafter, you can use PASDBG's GO/EXIT command 
to start the target application. The command starts target execution, 
then returns control to the host system monitor. You can then connect. 
to another target processor (using an indirect command file) prior to 
loading and executing the next target application. If you are 
debugging with multiple host PASDBG processes, use the PASDBG GO 
command to initiate target execution and continue running with PASDBG. 
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3.6.5.3 Setting Breakpoints and Watchpoints - You can set breakpoints 
and watchpoints in a system that has several processors by following 
the steps listed below. 

1. Connect to the first processor (see Section 3.6.5). 

2. Load symbols (LOAD/SYM command). 

3. Set the breakpoints and/or watchpoints. 


4, Start up the target application and exit PASDBG with a 
GO/EXIT command. 


The processor is now running with the breakpoint(s) and/or 
watchpoint(s) set. You can connect to other processors and set other 
breakpoints and/or watchpoints if desired. You should start all 


KXT11-C processors before starting the arbiter processor. If your 
arbiter processor is running a MicroPower/Pascal application, you can 
start it with PASDBG. If your arbiter is running under RSX-11 or 
RT-1l, you start your application using the appropriate 
system-specific command from the console terminal. 


PASDBG does not save the /AFTER and /PROCESS breakpoint and watchpoint 
modifiers if control is transferred to another processor. On 
reconnection to a processor, all breakpoints and watchpoints have 
modifiers of /AFTER=1 and /PROCESS=ALL. 


On reconnection to a processor, if a breakpoint or watchpoint has been 
triggered since the disconnect, the message UNKNOWN BREAKPOINT AT 
nmnnnnn is displayed at the terminal. To find the symbolic location, 
load the symbols (LOAD/SYM file.ext) and execute a SHOW TARGET 
command. The SHOW TARGET will symbolically display the location at 
which the target processor halted (the breakpoint location). The 
other processors in the system will continue to execute unless’ they 
are waiting for something from the processor that is halted at the 
breakpoint. 


3.6.6 Using the KK Handler Debugging Locations 


The KK handler uses two kernel locations, SKXTQW and SKXTQR, which are 
called (JSR PC instruction) just after the arbiter or KXT11-C places a 
message in the TPR command register. By setting breakpoints at either 
or both locations, you can examine the. communication sequence between 
the arbiter and a KXT11-C processor on a step-by-step basis. 


3.6.7 Debugging an Application in a KXT11-C with Battery Backup 


PASDBG's GO and INIT/RESTART commands start your application directly 
in the kernel's power-up modiile, bypassing the native firmware that 
sets up the power-up flags. Because of this, you must manually set up 
the flags before issuing these commands. 


The following procedures apply-when you are using PASDBG in a KxXT11-C 
system configured for battery backup (: POWER = NONVOL specified in 
KXT11C macro). | 
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To down-line load an application: 
1. Use PASDBG in ODT mode to open location 1759@2. 


2. Set bit 9 (power up without battery backup) to 1 and bit 19 
(power up with battery backup) to @. 


3. Load your application with the LOAD command. 
To restart a loaded application: 
1. Use PASDBG in ODT mode to open location 175882. 


2. Set bit 9 (power up without battery backup) to 1 and bit 18 
(power up with battery backup) to @. 


3. Issue the INIT/RESTART command. 
To test the power-failure and restart sequence: 
1. Use PASDBG in ODT mode to open location 1756882. 


2. Set bit 18 (power up with battery backup) to 1 and bit 9 
(power up without battery backup) to 9g. 


3. Set kernel location KXTSPF to a nonzero value. 

4. Issue the INIT/RESTART command. 
If you attempt to load or restart an application configured for 
battery backup, without first setting one of the flags, the target 


will crash. If that happens, enter ODT mode and _ follow the 
instructions above to repeat the down-line load. 


CHAPTER 4 


THE KXT11-C AND YOUR RSX-11 OR RT-11 ARBITER APPLICATION 


This chapter describes KXT11-C peripheral processor application 
development for target systems that use an arbiter application in an 
RT-11 or RSX-11 system environment. For these target systems, there 
are three types of application development software: 


@® MicroPower/Pascal software for programming the KXT11-C 
e RT-11 or RSX-11 software to operate on the arbiter system 


@ KXT11-C/RT-11 Peripheral Processor Tool Kit or KXT11-C/RSX-11 
Peripheral Processor Tool Kit 


Each tool kit provides a KX device handler and the KUI program for 
peripheral processor loading and control. 


MicroPower/Pascal KXT11-C software makes the KXT11-C look (to an 
arbiter system) like a traditional Q-BUS I/O device. The KX handler 
(MicroPower/Pascal, RSX-ll and RT-11 versions) treats the two-port RAM 
(and the KK handler on the KXT11-C) as a standard I/O device, and the 
KXT11-C is configured into a system just like any other device. In 
addition, the DMA transfer controller (QD) device handler gives you a 
high-speed data path that is similar to other Q-BUS DMA devices. 


The design considerations identified in Section 3.5 apply to arbiter 
applications that use RT-11 and RSX-11l. The major differences between 
these arbiter applications and MicroPower/Pascal arbiter applications 
are the implementation language and the lack of MicroPower/Pascal 
features such as semaphores and run-time hardware support routines. 


4.1 KUI UTILITY COMMANDS 


The KUI program provides’ the following peripheral processing 
development support and final application support. 


e SET and SHOW commands to allocate a peripheral processor and 
display its status. 


@e Indirect file commands @, CLOSE, SUSPEND, and RESUME to manage 
the use of command file input. 


e LOG command to write a file containing the commands’ entered 
during a KUI session. The log file is executable as a command 
file. 
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e LOAD command to transfer executable images from the arbiter's 
mass storage device to a KXT1l1-C. 


@e EXECUTE command to start the program on the KXTI11-C. 


@e REINIT command to cause the KXT11-C native firmware to execute 
a bootstrap procedure. 


e ODT command to emulate the console ODT of the KxXTLI-C native 
firmware. — 


e TRAP command to cause the execution of a trap handling routine 


e SELFTEST command to selectively invoke the self-test routines 
in the KXT11-C native firmware. 


@e EXIT command to terminate execution of the KUI program and 
return to the system's command line interpreter. 


4.2 ARBITER APPLICATIONS THAT USE RT-11 


4.2.1 Interface Tools 


The KX handler supplied with the KXT11-C/RT-11 Peripheral Processor 
Tool Kit provides the primary interface between application code 
running under the RT-11 system and application code running on. the 
KXT11-C. The KX handler supports up to four KXT11-Cs where each 
KXT11-C provides two logical units. Logical unit numbering is 
determined when you build the handler or by subsequent SET KX CSR 
(DCL) commands. 


To support more than four KXT11-C processors, you must edit, rename, 
and rebuild the KX handler. The procedure for creating a second or 
subsequent handler appears in the tool kit documentation. 


The KX handler for RT-11 provides .OPEN, .CLOSE, .READ, and .WRITE 
programmed requests. 


e The .OPEN programmed request associates a user-specified 
channel number with a logical unit number of a KXT11-C. 


e The .CLOSE programmed request reverses the effect of the .OPEN 
programmed request, thus freeing the user's channel for use 
with another device or file. 


e The .READ programmed request transfers data from a_ peripheral 
processor to an arbiter buffer with three options: .READ, 
»READW and .READC. 


e The .WRITE programmed request transfers data from an arbiter 


buffer to a peripheral processor with three options: .WRITE, 
~WRITW and .WRITC. 


The RT-11 arbiter application may also interface the application on 
the KXT11-C using the KXT11-C's DMA transfer controller (DTC) and QD 
handler. This interface provides for the exchange of buffers of data 
between the arbiter and the KXT11-C using direct memory access. 
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The tool kit also provides the MACRO-11 macro KXTDFS that defines’ the 
registers of the KXT11-C and the commands and responses defined for 
the KX/KK protocol in Appendix A. This macro can be used when 
necessary to interface the KXT11-C directly without using the KX 
handler, or if the application requires access to the command and 
status registers used by the native firmware on the KXT11-C. 


In developing a peripheral processing application using an RT-11 
arbiter, you must follow the same steps that were outlined in Chapters 
2 and 3. The following are specific considerations that reflect the 
RT-11 operating system environment. 


4.2.2 Calculating Physical Memory Addresses 


If you want to use DMA transfers between the RT-1l arbiter's memory 
and the KXT11-C, you must provide a physical address to the QD handler 
on the KXT11-C. The RT-11 KX handler provides a special function 
(.SPFUN) that converts a 16-bit virtual address to a 22-bit physical 
address. 


In the RT-11 SJ and FB monitors, virtual addresses and physical 
addresses are identical. To facilitate the transportability of 
programs among all the RT-11 monitors (SJ, FB, and XM), you should use 
the .SPFUN function in the SJ and FB environments, as.-well as in the 
XM environment. 


4.2.3 Application Building for Debugging 


The same overall considerations apply to debugging an application 
using an RT-11 arbiter as apply to the MicroPower/Pascal arbiter, as 
outlined in Chapters 2 and 3. Conventional debugging tools, such as 
ODT, are available for debugging the arbiter-resident portion of the 
application. KUI may also be used during the debugging phase of 
development. The ODT and TRAP commands are particularly useful when 
debugging. It is helpful to include PASDBG in the KXT11-C application 
so you can use the two arbiter/KXT11-C debugging locations, SKXTQW and 
SKXTOR, described in Section 3.6.6. 


4.2.4 Final RT-11 Application’ Configuration 

Final application configuration considerations include removing the 
debugging features, adapting the application to its final loading 
method, and testing it in its final configuration. 


4.2.5 Loading a KXT11-C Peripheral Processor from the RT-11 Arbiter 


The KXT11-C application in its final configuration can be loaded using 
the KUI program, loaded from TU58 DECtape II, or resident in ROM. KUI 
supports the loading of .SAV, .LDA and .MIM files on RT-ll. Loading 
and starting the application with KUI can be automated by using 
command files at system start-up. Appendix F describes how a program 
can detect nonfatal errors reported when issuing the KUI commands 
REINIT or LOAD to the KXT11-C. 
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4.3 ARBITER APPLICATIONS THAT USE RSX-11 


4.3.1 Interface Tools 


The KX handler supplied with the KXT11-C/RSX-1l Peripheral Processor 
Tool Kit provides the primary interface to the KXT11-C. The KX device 
(handler) has one unit number associated with each data channel in 
each KXT11-C two-port RAM area. These units are assigned to their 
respective data channels at the time the KX handler is generated. 
This handler is a conventional RSX-11 handler providing the standard 
requests IO.RVB, IO.WVB, IO.ATT, and IO.DET.. 


Another interface is through shared memory areas using the DTC and the 
QD handler on the KxT11-C. This interface is faster than the KX 
handler, especially for larger data blocks, but is more complex to use 
and requires special precautions. 


The tool kit also provides the MACRO-11l macro KXTDFS that defines’ the 
registers of the kKXT11-C and the commands and responses defined for 
the KX/KK protocol in Appendix A. This macro can be used _ when 
necessary to interface the KXT11-C directly without using the KX 
handler, or if the application requires access to the command and 
status registers used by the native firmware on the KXTI11-C. 


In developing a peripheral processing application using an RSX-11 
arbiter, you must follow the same steps that were outlined in Chapters 
2 and 3. The following are specific considerations that reflect the 
RSX-11 operating system environment. 


4.3.2 Calculating a Physical Memory Address 


You must calculate a physical address when transferring memory blocks 
to and from the arbiter memory space with the KXT11-C using the QD 
handler. Do this by using the get region parameters directive GREGS 
from the task containing the buffer. The GREGS directive returns the 


physical address of the beginning of the task region. Use this 
address plus the offset of the buffer from the beginning of the task 
to calculate the physical address of the buffer. This address can 


then be passed to the QD handler on the KxT11-c. 


4.3.3 Accessing Shared Memory Areas 


You must take precautions when using a shared memory area or a_ buffer 
that is accessed by the QD handler and DTC device. In RSX-11l systems 
the shuffler task can move a task from place to place in memory, so a 
task issuing a request to a KXT11-C can be moved between the time the 
request is issued and the time the KXT11-C attempts to move the data, 
leading to catastrophic results. ; 


You can lock a task in position by queuing an I/O request which 
increments the task's I/O-in-progress count; RSX-11 will not shuffle a 
task with I/O in progress. If, however, your application uses the KX 
handler to pass a buffer transfer request to the QD handler, the Kx 
handler request will complete, freeing the task to be swapped before 
the QD handler can move the data. This can lead to unpredictable and 
random failures of the application. 
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To prevent this problem, manually change the I/O-in-progress count to 
prevent task shuffling during critical periods, or use data partitions 
for the shared data areas. 


4.3.4 Protecting Shared Data Areas from Simultaneous Access 


RSX-11 does not provide. semaphore operations, so other means of 
protecting data areas from simultaneous access must be devised. You 


should design this protection into the protocol used in communicating 
with the KXT11-C. 


4.3.5 Application Building for Debugging 


You will probably include ODT or some other debugging tool in your 
RSX-11 application while debugging it. You can use the KUI program 
during the debugging phase of development. The ODT and TRAP commands 
are particularly useful when debugging. It is helpful to include 
PASDBG in the kKXT11-C application so you can use the two 
arbiter/KXT11-C debugging locations, SKXTQW and $KXTOQR, described in 
Section 3.6.6. 


4.3.6 Final RSX-11 Application Configuration 


Final application configuration considerations include removing the 
debugging features, adapting the application to its final loading 
method, and testing it in its final configuration. 


4.3.7 Loading a KXT11-C Peripheral Processor from the RSX-11 Arbiter 


The KXT11-C application in its final configuration can be loaded using 
the KUI program, or resident in ROM. KUI can load memory image files 
with the .TSK and .MIM file types. Loading and starting the 
application with KUI can be automated by using command files at system 
start-up. Appendix F describes how a program can detect nonfatal 
errors reported when issuing the KUI commands REINIT or LOAD to the 
KXT11-C. 
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APPENDIX A 


KX/KK DEVICE HANDLER COMMUNICATION PROTOCOL 


This appendix describes the protocol that the KK and KX device 
handlers use to communicate with one another through the two-port RAM 
(TPR). It contains information to assist you in designing your own KK 
or KX device handler so it can communicate with the DIGITAL-supplied 
KK or KX handler. The KK and KX handlers are used when the KXT11-C is 
set up for peripheral processor operation. 


The protocol provides a master-slave relationship between the arbiter 
processor and the KxXT11-C (do not confuse master-slave with the 
bus-master/bus-slave hardware concept). The KK handler running on the 
KXT11-C uses the TPR to emulate a traditional Q-BUS peripheral device. 
The KX handler running on the arbiter communicates with this device. 
The protocol implements a request-reply dialog between the arbiter on 
the Q-BUS and the KXT11-C to assure correct and complete transfer of 
data between them. 


The arbiter is the master in all transactions with the peripheral 
processor which is the slave (refer to Figure A-1). The peripheral 
processor must receive a command from the arbiter before it passes any 
data to the arbiter or before it receives any data from the arbiter. 


A.1 COMMUNICATION MECHANISMS 
The basic TPR hardware communication mechanisms are the: 


e Command register for each data channel -- used by the master 
to pass commands to the slave 


e Status register for each data channel -- used by the slave to 
pass error and operational status to the master 


@® Data registers -- 4 bytes for data channel @ and 12 bytes for 
data channel 1, used for passing data between the master and 
the slave 


@e QIR register in the slave -- used by the slave to interrupt 
the master 
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Arbiter 


Channel 1 Channel 1 


Data Register 


Status Register 


Command Register 
KX 


Handler 
Channel 0 





Figure A-l: KX/KK Device Handler Communication Linkages 


The interface between the arbiter and the KXT11-C consists of layers 
of software. The lowest layer contains MACRO definitions for the bits 
in the command and status registers of the TPR. The next layer 
consists of KX and KK handlers that move data between a KXT11-C 
process and a process in the arbiter. 


The protocol provides the arbiter with commands that cause the: 
e Device initialization of the peripheral processor 
ee Arbiter read request/ peripheral processor write reply sequence 
e Arbiter write request/peripheral processor read reply sequence 


e Enabling and disabling interrupts from the peripheral 
processor to the arbiter 


The following sections describe the special meanings the protocol 
assigns to the TPR registers in the context of KX/KK handler 
operations. Figure A-2 shows the TPR's general layout. 
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Data Channel 1 


KW.DST 
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Base + 20 


Data Channel 0 
KW.DST 


Note l Writing to this register from the arbiter causes a level 5 
interrupt through vector 124 on the KXT11-C. 


KW.DCO 





Base + 10 


+ 


KXT11-C 
System Control 
Registers 
(note 4) 


Base + 00 


Note 2 Writing to this register from the arbiter causes a level 5 
interrupt through vector 12@ on the KXT11-C. 


Note 3 Writing to this register from the arbiter causes the KXT11-C 
to restart the native firmware. 


Note 4 The system control registers are not part of the protocol. 
They are used by the KUI utility program, the KXT_LOAD 
procedure, diagnostic programs, and user-written programs. 


Figure A-2: TPR Register Layout 


A.2 KX/KK PROTOCOL DEFINITION 


In the protocol a data channel's command register (KW.DCO in Figure 
A-2) controls ownership of the contents of the data channel's data 
register. If the command register is 9, the KX handler owns the data 
channel's registers. If the command register is nonzero, the KK 
handler owns them. All status registers (KW.DST in Figure A-2) are 
owned by the KK handler. 


When the KX handler communicates with the KK handler with interrupts 
disabled, it must poll the command register (KW.DCO) using it as the 
ownership flag for the data channel. To poll the KK handler, the KX 
handler must: 


1. Poll the command register until it becomes zero. The zero 


condition means the KK handler is idle and any previous 
command has completed. 
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2. Issue a command by writing it into the command register. 
This causes the KK handler to perform the command. Once the 
command register has been written, the KX handler cannot 
alter the contents of any of the data channel's registers. 
Consequently the KX handler must write the data being 
transferred by the command into the data registers before the 
command is issued. 


3. Poll the command register until it becomes zero. At that 
time, the status register data is valid and the KX handler 
can issue further commands (as in step 2). 


When the KX handler communicates with the KK handler with interrupts 
enabled, the KK device handler uses the Q-BUS interrupt register (QIR) 
to signal the KX handler that an operation is complete. The KK 
handler interrupts the KX handler after a command has completed and 
the proper status and/or data bits have been set. 


By using the interrupt-on-data-available (KC.IDA) and interrupt-on- 
data-requested (KC.IDR) bits of the enable interrupts command, the KX 
handler can instruct the KK handler to interrupt the KX handler when 
the KS.DA and/or KS.DR status register bits change from 8 to l. This 
presents a device-like interface analogous to a physical device's 
receive-buffer-full and transmit-buffer-empty interrupts. 


A.2.1 KX and KK Handler Transactions 


The transactions between the KX handler and the KK handler are 
illustrated below. 


1. The KX handler tests the command register. If it is zero, 
the handler proceeds to the next step. If nonzero, the 
handler repeats this step. 


KX HANDLER KK HANDLER 










Data Register 


Status Register 
Command Register 


Is it Zero? «<— 


2. Since the command register is zero, the KX handfer owns’ the 
data channel. It can write data to or read data from the 
data registers, as implied by the pending command. The KX 
handler issues the command by writing it to the command 
register. The act of writing the command to the command. 
register, thereby making it nonzero, switches ownership of 
the data channel to the KK handler. 
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KX HANDLER KK HANDLER 
Read/Write data ~<#— Data Register 
Command ——> Command Register 





The KK handler is interrupted by the KX handler writing to 
the command register. The KK handler now owns the data 
channel. It reads and validates the command. 


KX HANDLER KK HANDLER 


Command Register 


Tf the KK handler detects an error in the command, it reports 
this error in the status register and proceeds with step 4. 





—s Validate the command 





KX HANDLER . KK HANDLER 


Status Register 
Command Register 


If it detects no error, the KK handler performs the command, 
moves any data required by the command into or out of the 
data registers, and writes the status of the channel into the 
status register. 





<@— Channel! Error Status 






KX HANDLER KK HANDLER 


Data Register <@—e Read/Write any data 


Status Register <!— Channel Status 


Command Register ——® Read the command 





The KK handler completes the transaction by zeroing the 
command register, thus transferring ownership of the data 
channel back to the KX handler. If interrupts are enabled, 
the KK handler interrupts the KX handler by queuing an 
interrupt to the Q-BUS interrupt register (QIR). 


KX/KK DEVICE HANDLER COMMUNICATION PROTOCOL 


KX HANDLER KK HANDLER 


Data Register 


Status Register 


Command Register ~<«— Zero 





5. Finally, the KX handler regains ownership of the data channel 
; by: 


Polling the command register and testing for zero 
or 


Waiting for an interrupt and testing the command register 
on being interrupted to find it is zero 


Once it gains ownership, the KX handler checks the status 
register for error and status information and reads from or 
writes to the data registers as implied by the pending 
command. From this point the cycle repeats. 


KX HANDLER KK HANDLER 


Read/Write data <> Data Register 
Status ~<—+— Status Register 


Is it Zero? ~+— Command Register 





A.2.2 Message Communication Between the KK and KX Handlers 


In the transactions between the KX and KK handlers over the TPR 
(Section A.2.1), the number of bytes in a data transfer is limited by 
the number of data registers in the channel (4 bytes for data channel 
9 and 12 bytes for data channel 1). At the application-program 
handler level of communication, however, the protocol provides for 
longer messages by using an end-of-message (EOM) indicator. Thus, a- 
read or write request to the KX handler causes multiple transactions 


over the TPR if the message is larger than the size of the data 
channel. . 


When the KX handler receives a write request from the arbiter program, 
it performs as many TPR write operations as necessary to send the 
message. For each TPR write operation, the KK handler completes’ the 
transaction by performing a corresponding TPR read operation. On the 
last write operation, the KX handler sets the EOM indicator in the 
data channel's status register. This informs the KK handler that all 
data has been sent. Therefore, the arbiter program's write request is 
complete. 


When the KX handler receives a read request from the arbiter program, 
it performs as many TPR read operations as necessary to receive the 
message. For each TPR read operation, the KK handler completes’ the 
transaction by performing a corresponding TPR write operation. On the 
last TPR write operation, the KK handler sets the EOM indicator in the 


KX/KK DEVICE HANDLER COMMUNICATION PROTOCOL 


data channel's status register. This informs the KX handler that all 
data has been sent. Therefore the program's read request is complete. 
Accordingly, the number of bytes received can be less than the number 
of bytes specified in the arbiter program's read request. 


A.2.3 Synchronizing KK and KX Device Handler Operation 


For a TPR read operation by the KX handler to complete, there must be 
a corresponding TPR write operation by the KX handler. Similarly, a 
TPR write operation by the KX handler requires a TPR read operation by 
the KK handler. If the KX handler issues a TPR read operation and the 
KK handler has not posted a TPR write operation, the KX handler 
receives an error indicating no data is available. 


To optimize synchronization of TPR operations, the KX and KK handlers 
use two interrupts: interrupt when data available and interrupt when 
data requested (Sections A.3.1.2 and A.3.1.3). By using these 
interrupts the handlers need not continually issue and retry commands 
because of data-not-—requested or data-not-available error conditions. 


A.2.3.1 Interrupting When Data is Available - The KX handler uses the 
interrupt-when-data-available as follows. 


1. Before issuing a TPR read command it checks for TPR data 
available. 


2. If data is available, it issues the read command and returns, 
waiting for an interrupt on completion. 


If data is not available, it does not issue the read command. 
Instead, it saves its context and returns, waiting for an 
interrupt on data available. 


When the KK handler issues a TPR write command, it sets’ the 
data-available indicator and requests an interrupt. When the KX 
handler receives the interrupt, it checks that it has a TPR read 
command pending and that data is available before issuing its TPR read 
command. 


The KK handler can request an interrupt-when-data-available when it 
has no read pending. The KX handler ignores these interrupts. 


A.2.3.2 Interrupting When Data is Requested - The KX handler uses the 
interrupt-when-data-requested as follows. 


1. Before issuing a TPR write command it checks for TPR data 
requested. 


2. If data is requested, it issues the write command and 
returns, waiting for an interrupt on completion. 


If data is not requested, it does not issue the write 
command. Instead, it saves its context and returns, waiting 
for an interrupt on data requested. 
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When the KK handler issues a TPR read command, it sets the 
data-requested indicator and requests an interrupt. When the KX 
handler receives the interrupt, it checks that it has a TPR write 
command pending and that data is requested before issuing its TPR 
write command. 


The KK handler can request an interrupt-when-data-requested when it 
has no write pending. The KX handler ignores these interrupts. 


A.3 REGISTER DEFINITIONS 


The following sections define the command and status registers as 
viewed from the Q-BUS (KX handler) side of the interface between the 
Q-BUS and the KXT11-C. 


A.3.1 Command Register Definition 


1514131211109 876543210 
KW.DCO 


on Command field (KC.COM) 
Interrupt when data available (KC.IDA) 
Interrupt when data requested (KC.IDR) 
Length field (KC.LEN) 


: End of message (KC.EOM) 
ae 
Ao Vector number field (KC.VEC) 


Bit 5 is set to 9. Bits KC.IDA, KC.IDR, KC.LEN, KC.EOM, and KC.VEC 
have meaning for specific commands only. 


A.3.1.1 Command Field (KC.COM) - The command field, KC.COM, contains 
one of the following commands, issued to the KK handler from the KX 
handler. The codes are designed to allow your program to index them 
from a table. 


No-Op Command KCSNOP (Code @) 


A null operation. The KK handler places the data channel's status in 
the status register (KW.DST) and clears the command: register (KW.DCO). 
If interrupts are enabled (KCSEI command) a Q-BUS interrupt occurs. 
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Reset KK Handler to KX Handler Command KCSRSM (Code 2) 


Resets ownership of the TPR to the KX handler. The KK handler reports 
the channel's status in the status register (KW.DST) and clears the 
command register (KW.DCO). If interrupts are enabled (KCSEI command) 
a Q-BUS interrupt occurs. 


Enable Interrupt Command KCSEI (Code 4) 


Enables interrupt mode in the KK handler. The address of the vector 
to use must be in the kKC.VEC field (bits 8 to 15) of the command 
register and must be the vector address divided by four. 


The KK handler interrupts the KX handler under any of these 
conditions. 


1. Command completion 


2. If the KS.DA bit in the status register changes from 9 to 1 
when the interrupt-when-data-available bit (KC.IDA) is set 


3. If the KS.DR bit in the status register changes from 9 to 1 
when the interrupt-when-data-requested bit (KC.IDR) is set 


The KK handler interrupts the KX handler on command completion when 
the interrupt mode is enabled. Conditions 2 and 3 (above) cause the 
KK handler to interrupt the KX handler only if the KC.IDA and KC.IDR 
bits are set when the command is issued (see Sections A.3.1.2 and 
A.3.1.3). Before interrupting the KX handler, the KK handler places 
the channel's status in the status register and clears the command 
register. , 


Disable Interrupt Command KCSDI (Code 6) 


Disables interrupt mode in the KK handler. The KK handler places the 
channel's status in the status register and clears the command 
register. Completion of the command never interrupts the KX handler. 


Get Status Command KCSGS (Code 8) 


Instructs KK handler to place its internal status in the data 
registers. This status information is currently undefined and 
reserved by DIGITAL for future use. The command is effectively the 
same as the no-op command. The KK handler places the channel status 
in the status register and clears the command register. If interrupts 
are enabled (KCSEI command) a Q-BUS interrupt occurs. 


Read Status Command KCSSS (Code 19) 


Instructs KK handler to read the new internal status from the data 
registers. This status information is currently undefined and 
reserved by DIGITAL for future use. The command is effectively the 
same as the no-op command. The KK handler places the channel's status 
in the status register and clears the command register. If interrupts 
are enabled (KCSEI command) a Q-BUS interrupt occurs. 
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Read Data Command KCSRD (Code 12) 


Causes KK handler to place bytes of data into the channel's data 
registers. The maximum number of bytes to transfer is specified by 
data length field KC.LEN (see Section A.3.1.4). The KK handler must 
be ready to send the data (as indicated by the data-available KS.DA 
bit in the status register) or it will return a no-data-available 
(KESNDA) error in the status register. 


The KK handler: 
1. Moves the data into the data registers 


2. Sets the number of bytes being transferred in the actual 
length field (KS.ALN) of the status register 


3. Sets the end-of-message bit (KS.EOM) in the status register 
if this is the last transfer in the message 


4. Sets any other status 


5. Clears the command register and interrupts the arbiter if 
interrupts are enabled 


If the KX handler buffer being filled with data overflows, the XxX 
handler issues a reset KK-handler-to-KX-handler command (KCSRSM) 
thereafter. If interrupts are enabled (KCSEI command), a Q-BUS 
interrupt occurs. 


Write Data Command KCSWD (Code 14) 


Causes KK handler to accept bytes of data from the channel's data 
registers. The maximum number of bytes to transfer is specified by 
data length field KC.LEN (see Section A.3.1.4). The KK handler must 
be ready to accept the data (as indicated by the data-requested KS.DR 
bit in the status register) or it will return the no-data~requested 
(KESNDR) error in the status register. If the KK handler buffer being 
filled with data overflows, excess data is discarded and the KK 
handler returns a data overrun (KESOVR) error. | 


The KK handler: 


1. Examines the length field (KC.LEN) for the number of bytes 
being transferred 


2. Removes the number of bytes specified by KC.LEN from the data 
registers 


3. Tests for the EOM bit (KC.EOM) to find the last transfer in 
the message 


4. Places its status in the status register 


5. Clears the command register and interrupts the arbiter if 
interrupts are enabled 
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A.3.1.2 Interrupt When Data Available Bit (KC.IDA) - The interrupt- 
when-data-available bit, KC.IDA, when set to 1 indicates the KK 
handler should interrupt the KX handler wnen the data-available bit 
(KS.DA) of the status register changes from 9 to 1. This bit is 
meaningful only when used with the KCSEI command. 


A.3.1.3 Interrupt When Data Requested Bit (KC.IDR) - The interrupt- 
when-data-requested bit, KC.IDR, when set to 1 indicates the KK 
handler should interrupt the KX handler when the data-requested bit 
(KS.DR) in the status register changes from @ to l. This bit is 
meaningful only when used with the KCSEI command. 


A.3.1.4 Length Field (KC.LEN) - The length field, KC.LEN, indicates 
the maximum number of bytes to be transferred by the read-data (KCSRD) 
and write-data (KCSWD) commands. This field is meaningful only when 
used with the KCSRD and KCSWD commands. 


A.3.1.5 End-of-Message Bit (KC.EOM) - The end-of-message bit, KC.EOM, 
when set to 1 indicates the last byte in the current transfer that 


ends the message. This bit is meaningful only when used with the 
KCSWD command. 


A.3.1.6 Vector Number Field (KC.VEC) - The vector number field, 
KC.VEC, specifies the vector number (vector address divided by four) 
of the interrupt vector being activated by the enable-interrupt 
command (KCSEI). This field is meaningful only when used with the 
KCSEI command. 


A.3.2 Status Register Definition 


1514131211109 876543210 
a el 


a Error code field (KS.ERC) 
Data requested (KS.DR) 
End of message (KS.EOM) 
Data available (KS.DA) 
Actual length field (KS.ALN) 
Interrupt enabled (KS.IEN) 
Interface ready (KS.ON) 
Cumulative error (KS.ERR) 


Bit 12 is set to @. 


KX/KK DEVICE HANDLER COMMUNICATION PROTOCOL 


A.3.2.1 Error Code Field (KS.ERC) - The error code field, KS.ERC, 
contains the following status or one of the following errors after a 
requested command operation. The codes are designed to allow your 
program to index them from a table. 


Operation Successful Status KESOK (Code 9) 


The operation previously requested completed without errors. 


No Data Available Error KESNDA (Code 2) 


The read data command (KCSRD) was rejected because no data was 
available. 


No Data Requested Error KESNDR (Code 4) 


The write data command (KCSWD) was rejected because no data was 
requested by the KK handler. 


Illegal Command Error KESILC (Code 6) 

The command specified in the command field (KC.COM) of the command 
register is invalid. 

Illegal Length Error KESILL (Code 8) 

The number of bytes specified in the length field (KC.LEN) of the 
command register is invalid. 

Illegal Vector Error KESILV (Code 198) 

The vector number (vector address divided by four) specified in the 
vector number field (KC.VEC) of the command register is invalid. 

KK Handler Buffer Overflow Error KESOVR (Code 12) 


The KK handler buffer being filled by a write data (KCSWD) command 
overflowed and excess data was discarded. 


A.3.2.2 Data Requested Bit (KS.DR) - The data-requested bit, KS.DR, 
when set to 1 indicates the KK handler is requesting data. Thus, a 
write data (KCSWD) command issued by the KX handler will be accepted 
by the KK handler. — 


A.3.2.3 End-of-Message Bit (KS.EOM) - The end-of-message bit, KS.EOM, 
when set to 1 indicates the last byte in the current transfer ends the 
message. 


KX/KK DEVICE HANDLER COMMUNICATION PROTOCOL 


A.3.2.4 Data Available Bit (KS.DA) - The data-available bit, KS.DA, 
when set to 1 indicates data is available to be read from the KK 
handler. Thus, the KK handler will accept a read data (KCSRD) command 
issued by the KX handler. 


A.3.2.5 Actual Length Field (KS.ALN) - The actual-length field, 
KS.ALN, is set to the number of bytes to be transferred in response to 
a read data (KCSRD) command. 


A.3.2.6 Interrupt Enabled Bit (KS.IEN) - The interrupt-enabled bit, 
KS.IEN, when set tol indicates an enable interrupt (KCSEI) command 
completed successfully and the KK handler will interrupt the arbiter 
on the specified interrupt condition. 


A.3.2.7 Interface Ready Bit (KS.ON) - The interface-ready bit, KS.ON, 
when set to 1 indicates to the KX handler that the KK handler is ready 
to perform the protocol. 


A.3.2.8 Cumulative Error Bit (KS.ERR) - The cumulative error bit, 
KS.ERR, when set to 1 indicates an error condition exists. The error 
code is in the error code (KS.ERC) field. .When this bit is set to lf, 
the KS.ALN field is not meaningful and its contents should be ignored. 


A.3.3 Interface Initialization 


At system start-up the TPR is locked from write access by the KX 
handler side, and the status and command registers are in a cleared 
state. The KX handler waits for the KK handler to initialize itself, 
and indicates its readiness by waiting for the interface-ready bit 
(KS.ON) in the status register to be set to 1. The KK handler cannot 
clear the KS.ON bit until it has permanently ceased TPR communication. 
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APPENDIX B 


KXT11-C CSR AND VECTOR ASSIGNMENTS 


This appendix lists the interrupt vector assignments for all KXT11-C 
and their associated control status registers (CSRs). Refer 
to Appendix C for the interrupt vector and CSR assignments for the 
two-port RAM (TPR). 


devices 


Vector 


68 


64 


79 


1090 


194 


119 


CSR 
Address Device 


17756@- SLU1 console 
177562 DLART receiver 


177564-—- SLU1 console 
177566 DLART 
transmitter 


17570@- SLU2 hardware 
175716 


17572G- 8254 timer @ 
175736 and timer 1 


177520 Line frequency 
clock 


175720- 8254 timer 2 
175736 


174498~ DTC channel @ 
174536 


Comments 


Do not specify this vector as an 
argument to the MicroPower/Pascal 
DEVICES macro. The kernel routes its 
interrupts from this vector ‘through 
vectors 149 to 174. 


Timer @ and timer 1 onthe 8254 
device provide timing for SLU2. 


Interrupts through this vector are 


enabled in the MicroPower/Pascal 
kernel if CLOCK=ON in the kXKxXTILIC 
macro. The MicroPower/Pascal clock 


handler enables the interrupt with or 
without specifying CLOCK=ON. 


CSR 177529 is KXTCSRA. Bit 6 
enables/disables the line frequency 
clock as in the usual clock CSR at 
177546. However, the other bits are 
allocated to serve other functions. 


MicroPower/Pascal does not support 
this timer. You must write your own 
handler for it. Specify vector 104 
in the MicroPower/Pascal DEVICES 
macro. Timer 2 is enabled by bit 7 
in KXTCSRA (address 1775290). 


The native firmware sets up this 
vector. 


114 


126 


124 


134 


149 


144 


158 


154 


169 


174400 
174536 


175808- 
175896 


175919- 
1759816 


175820- 
175836 


177532 


175936- 
175936 


175709- 


175736 
175796- 
175736 


1757909- 
175736 


175799- 
175736 


175709- 
175736 
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DTC channel 1 


TPR system 
control 


TPR data 
channel @ 


TPR data 
channel 1 


QIR 


Q-BUS 
interrupt 
answer-back 


TPR data 
channel 2 


SLU2 channel A 
character 
received 


SLU2 channel A 
character sent 


SLU2 channel A 
error 


SLU2 channel A 
modem control 


SLU2 channel B 
character 
received 


locations as the 


vector in the 


The native firmware this 


vector. 


sets up 


The first four words of the two-port 
RAM used for KXT11-C native firmware/ 
arbiter communication. When the 
arbiter writes to word @ (TPR command 
register), the kKXT11-C restarts at 
173904. 


This vector is used when the arbiter 
writes to TPR word 4 (command 
register for data channel 9). 


This vector is used when the arbiter 
writes to TPR word 8 (command 
register for data channel 1). 


Q-BUS interrupt 
MicroPower/Pascal KK device handler 
writes the arbiter's vector address 
to use for TPR operations. . 


register. The 


This vector is used when the arbiter 
acknowledges the interrupt requested 
by the MicroPower/Pascal KK device 


handler over the QIR. 


This vector is used when the arbiter 
writes to word 12 of the TPR (enabled 
by a bit in KXTCSRD). Words 12 to 15 


of the TPR form data channel 2 which 
is not supported by the MicroPower/ 
Pascal KK/KX device handlers. 


Instead, MicroPower/Pascal uses these 
last four words of 
Do not specify this 

MicroPower/Pascal 


data channel l. 
DEVICES macro. 


Module KSLU2 in MicroPower/Pascal's 
kernel fans out the interrupts from 
SLU2, the multiprotocol chip, through 
the vector at 7@ to the vectors 149 

to 174. 


164 
17 
174 


298 
294 
219 


214 


229 


175766- 
175736 


1757980- 
175736 


175789- 


175736 


177899- 
177148 


177688- 
17714@ 


177889- 
177148 
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SLU2 channel B 
character sent 


SLU2 channel B 
error 


SLU2 channel B 
modem control 


Parallel I/0 
port A 


Parallel I/0 
port B 


Parallel I/0 
timers 


Nonvolatile 
RAM 
power restore 


Arbiter RESET 


This vector is set up by the kKxXT11-C 


native firmware and used by parallel 
I/O port A. 


This vector is set up by the kKxT11-C 
native firmware and used by parallel 
I/O port B. 


This vector is set up by the kKXT11-C 
native firmware and used by parallel 
I/O port counter-timers. 


This vector is used by MicroPower/ 
Pascal when the KXT11-C, set up for 
battery backup, performs a power 
restore operation. You must specify 


POWER=NONVOL in the kKXT11C macro to 
obtain this service. A user 
interrupt service routine connected 


to this vector is called during a 
power recovery. 


This vector is used when the 
arbiter's BRESET signal is asserted. 
BRESET is asserted when the arbiter 
executes a RESET instruction or its 


RESTART switch is toggled. 


enabled 
in the 


Many device interrupts are 
and disabled by setting bits 
CSRs. 


APPENDIX C 


SYSTEM ID SWITCH POSITIONS, TWO-PORT RAM CSR AND VECTOR ASSIGNMENTS 


This appendix shows the control status register (CSR) and interrupt 
vector assignments for the two-port RAM (TPR) that are selected by the 
KXT11-C system ID switch. These registers and vectors appear in the 
I/O page and vector area of arbiter memory. The table also shows the 
associated KX device handler logical unit IDs. 


The KX device handler passes data between the arbiter CPU and up to 14 
KXT11-C peripheral processors running on the Q-BUS. The handler 
communicates with the KK device handler in the KXT11-C through the 
command and status registers in the data channel areas of the TPR (see 
Sections 3.4.6 and 3.4.7 and Appendix A for more information). 


ID MicroPower TPR Base Address Default Vectors 
Switch KX Handler Jumper Jumper MicroPower 
Position ID In Out and RSX-1l RT-11 
G Stand-alone mode 
1 Stand-alone mode 
2 A 17762190 17769190 588,594 349,344 
3 B 17762148 177681498 519,514 350,354 
4 c 177622900 17760200 529,524 360,364 
5 D 17762248 17760249 539,534 378,374 
6 E 17762300 17769300 540,544 * 
7 F 17762349 17768348 550,554 * 
8 G 17777400 17775489 569,564 * 
9 H 17777448 177754480 578,574 * 
1G I 17777588 17775508 689,694 x 
De J 17777548 17775548 619,614 al 
12 K 17777606 17775608 620,624 * 
13 L 17777648 17775648 639,634 * 
14 M 17777708 17775708 648,644 * 
LS N 17777748 17775748 658,654 = 
*RT-11 device handlers have no more than eight logical units. Since 
two units are assigned to each KXT11-C, an RT-11 KX handler’ can 
support no more than four KXT11-C peripheral processors. For each 
four additional KXT11-C processors you want to use on an RT-11l 


system, you must rename, edit and rebuild the handler. The KXT11-C 
Software Toolkit/RT Reference Manual describes the procedure to build 
the second and subsequent KX handlers. 


Since RT-11 uses memory above location 598 for passing data during 
-CHAIN operations, you must restrict all KXT11-C vectors to less than 
588, thus allocating vectors to the KX handler that are not in use by 
other devices in the system. 


APPENDIX D 


SAMPLE MICROPOWER/PASCAL CONFIGURATION FILE 


The following is a copy of the MicroPower/Pascal configuration file 
that you must edit according to your hardware and software 
requirements in preparation for building a KXT11-C application. 


-enabl GBL 
-mcall CONF IGURATION 


+ 


-Module name: CFDKTC.MAC 
System: MicroPower/Pascal 
Functional Description: 


This module describes the hardware and system software configuration on 
which the application system is to run. It must be edited by the user 
and assembled. The resulting object module is used to build the kernel. 
This file has been edited for a typical ROM/RAM system on a KXTI11-C, 
including debug symbols and NOT including kernel optimizations. 


The following set of macros may be used in this file. The CONFIGURATION 
macro must be the first macro evoked. The ENDCFG macro must be the last. 
A configuration file must contain at the minimum the CONFIGURATION, 
SYSTEM, PROCESSOR, KXT11C, MEMORY, DEVICES, and ENDCFG macros. 


CONFIGURATION {name} 


SYSTEM optimize[=NO] ,debug [=NO] 

PROCESSOR mmu={NO], fpu{=FP11;=FIS}, type[=L1123], vector [=1999]} 

MEMORY base[=8], size(=@], type[=RAM], parity[=NO], csr[=9] 

DEVICES vl,v2,...,v6 

RESOURCES stack[=..KIS],packets[=20.],structures[=3990.],ramtbl[=29.] 

PRIMITIVES pl{=ALL],p2,p3,p4,p5,p6 

KXT11 nxm[=HALT], break[=TRAP], syshalt[=ODTROM], level7[=TRAP], 
slul [+9600], slu2[=960@] 

KXT1IC bhalt=NO, reset=IGNORE, clock=OFF, power=BOOT, map=9 


TRAPS tl{=ALL;t1l},t2,t3,t4,t5,t6,t7,t8 
. ALL - TR4, T18, BPT, EMT, and TRP (std. LSI-11 set) 

‘TR4 - Trap to 4 (bus timeout) 
T19 —~ Trap to 18 (reserved instruction) 
BPT - Breakpoint instruction trap 
EMT - EMT instruction trap 
TRP - TRAP instruction trap 
MPT - Memory parity error 


TOTO TT ETT TET OTT PETE PTR POPE TTT P TT EPO TE TTP ETE OTT T ECT EPPO EEE E OPE EOE EOE 
KXT11C Configuration Macro 

This macro defines the KXT11-C power-up configuration. The macro 
has the parameters listed below, with the DEFAULTS being the first 


ones listed: 


BHALT ... Used to indicate if Q-bus debug traps (B-HALTs) are 
to cause the routine at SKXTDB to be called. The user 
can put a PASDBG breakpoint there. 


me MO TO Me TO NO Me NE Te NO NO TO TH ME NO NO NO TO We TE TO We Te Te TO NO NO NO Se Ne Ne NO NE NO Ne NO WE Ne TO NO NE NE TO Ne Ne NE NE NO NO 
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SAMPLE MICROPOWER/PASCAL CONFIGURATION FILE 


Parameters ....NO No debug traps are provided on B-halt 
YES Debug traps are provided on B-halt 


RESET ... Used to indicate the action to take on a Q-bus reset. 


parameters. .... IGNORE Q-bus resets are ignored by the KXxT 
. BOOT Q-bus resets cause a KXT power-up. 
RSTBOT Q-bus reset causes KXT reset then power-up. 
INTRPT An interrupt is dispatched to vector 229. 
The ISR must call or jump to SKXTPU 


(KXTLI-C power-up routine) when complete. 


CLOCK ... Used to indicate whether or not to enable the Real-time clock 
interrupts on the KXT11C through vector 199. 


Parameters ... OFF The real-time clock is not enabled at power-up 
ON The real-time clock is enabled a power-up 


POWER ... Used to indicate the action to take on a power-fail and 
subsequent power-up. 


parameters ... BOOT No power-fail or power-recover processing 
will be done. Every trap through the restart 
vector will be treated like a power-up. 


NONVOL ... The non-volatile RAM support routines 
will be used. When debugging, INIT/RESTARTS 
by PASDBG present a special problem. Prior 
to restarting the user must set bit 9 at 
octal address 175002 for a power-up, or set 
bit 18 to test power recover. 


MAP ... Used to set the KXT1LIC memory configuration. 


parameter ... 9@..7 The map parameter must be set to an integer 
between @ and 7 which corresponds to the 
memory map jumper settings on the KXTLIC. 
The parameter is used to select the address 
of the power-fail flags which ODT and the 
kernel will use. The last 2 words of native 
RAM are used. Serial ODT uses 68 bytes before 
that as its scratch pad. 


me ME MO NO Ne TO TO Te WS We Te We RO WO WH We TWH TSO WS Te TO TH We WE VS Vs WO Ws We WO We Ns NTs Ne WE WO WS We NS Te We TO TH NS NE 


7 oe Ae A I 2 0 0 000 20002222222 220222002 
CONFIGURATION 

SYSTEM debug=YES, optimize=YES 

PROCESSOR mmu=NO, type=KXT11C, vector=224 

MEMORY base=<9>, size=<777>, type=RAM, volatile=NO 


(note that the highest 64 bytes of the native RAM can not be configured, 
because they are used by the native firmware) 


me se me 


RESOURCES packets=29., structures=2048. 


PRIMITIVES ALL 


KXT11C bhalt=YES, reset=IGNORE, clock=OFF, power=BOOT, map=@ 


TRAPS ALL 

DEVICES 690,64 ;Console Serial line 
DEVICES 198,194 ;RTC and Spare Timer 
DEVICES 119,114 ;DMA Vectors 


DEVICES 


DEVICES 
DEVICES 


DEVICES 


DEVICES 
DEVICES 


ENDCFG 


SAMPLE MICROPOWER/PASCAL CONFIGURATION FILE 


120,124,136 


140,144,158,154 
168,164,178,174 


200,204,219 


214 
226 


;Two-port RAM arbiter write interrupts 


;SLU2 Pseudo-vectors - chan A. 
sSLU2 Pseudo-vectors - chan B. 


;PIO and Counter-Timers 


;Power Recover 
7;Q-BUS Reset 


APPENDIX E 


CALCULATING CHECKSUMS FOR PROMS 


This appendix tells you how to use the VMS DECprom program to 
calculate checksums for PROM devices (programmable read-only memories) 
on the KXT11-C. The checksums calculated by this method can be 
verified by the ROM checksum test performed by the KXT11-C self-tests 
in the native firmware. The KXT11-CA User's Guide hardware reference 
manual describes the algorithm that the ROM checksum test uses to 
calculate checksums. 


DECprom calculates only checksums for PDP-1ll processors based on a 
16-bit system word. The ROM checksum test in the KXT11-C native 
firmware expects that each PROM device will contain its own (byte) 
checksum. Therefore, you must calculate a separate checksum for each 
PROM device, then load the appropriate checksum value into the last 
location of each device. 


The procedure that follows assumes you know how to use DECprom. Refer 
to the VAX /VMS DECprom User's Guide for detailed reference 
information. 


1. Using an initialization file that is appropriate for your 
PROM devices, run DECprom. 


2. Set the system word width to 16 bits. 


3. Load the PROM devices from the input file type of your choice 
(.MIM, .LDA, .SAV) but leave the last location of each PROM 
empty. 


4, Exit DECprom. 


5. Perform steps 1 and 2 (above) but set the system word width 
to 8 bits. This allows DECprom to calculate a byte-wide 
checksum. 


6. LIST the contents of each PROM in a binary (.SAV) file. This 
will produce a file for the low-byte device and a file for 
the high-byte device. 


7. Calculate a separate checksum for each file (CALC_CHECKSUM 
command) . 


8. Store the appropriate checksum in the last location of each 
device (STORE CHECKSUM command). 


APPENDIX F 


DETECTING NONFATAL FIRMWARE ERROR CONDITIONS 


This appendix tells you how to determine the severity of nonfatal 
error conditions reported by the automatic self-tests performed by the 
KXT11-C native firmware. These error conditions can result when the 
boot/self-test switch is in position 1, 2, 3, 5, 8, 9 or 18 (see 
SECEION 3%535.3.2)% 


Not all failures of the kKXT11-C automatic self-tests inhibit 
application execution. By examining test result data, your 
application can determine its ability to execute despite the presence 
of these error conditions. 


Automatic self-tests report test results and status information in the 
status and data registers of the TPR system control area. This data 
is available to your application only after the tests complete and 
before other routines or handlers in the application use these 
registers. The KXT11-CA User's Guide hardware reference manual shows 
the format of the status registers and tells you how to interpret the 
test results. 





The procedure to use when checking results of these tests depends on 
your operating system environment. The following sections describe 
the procedures to follow when using the KXT11-C in stand-alone mode 


and in peripheral processing mode under MicroPower/Pascal, RT-11 and 
RSX-1l. 


F.1 STAND-ALONE MODE 


An application initialization routine should test for error conditions 
that are considered intolerable for the specific application (for 
example, DMA errors if the DMA controller is used by the application). 
If an error condition is found that is critical to the operation of 
the application, the code shout take the appropriate action for that 
particular situation. 


F.2 PERIPHERAL PROCESSING MODE 


The procedure to use depends on where the application resides. 


DETECTING NONFATAL FIRMWARE ERROR CONDITIONS 


F.2.1 Application in ROM 


This is similar to the stand-alone environment. Once the application 
code is entered on power-up, it should check for critical error 
responses from the automatic self-tests and indicate the conditions to 
the arbiter using your application's communication protocol. 


F.2.2 Application Loaded from Arbiter with MicroPower/Pascal 


The KXT_LOAD utility procedure will not load the KXT11-C if there are 
any error conditions. If you load the KXT11-C in some other fashion, 
you can write a program, as described in Section F.2.3, to check for 
error conditions. 


F.2.3 Application Loaded from Arbiter with RT-11 or RSX-11 


You use the KUI utility program to load an application in the RT-11 or 
RSX-11 environment. Before running KUI, however, you must create a 
small application program that examines the status registers in the 
system control area of the TPR for error conditions. This program 
should directly access these registers and examine the results of the 
automatic self-tests. To simplify this task, you can run this program 
and the KUI utility under the control of an RT-11 or RSX-11 command 
file using applicable parameters. 


Your program should perform the following tasks. 


1. Poll the system control area's status register for the 
waiting-for-command condition. 


2. Examine the composite error response in the TPR for relevant 
errors. 


3. If there is a relevant error, set a flag that can be passed 
back to the indirect command file processor. 


4, Repeat steps 1, 2 and 3 (above) for each additional KxXT11-C 
in the system. 


5. Return to the command file with the error Parameters set 
appropriately. 


The command file should then examine the returned parameters and _ take 
the appropriate action. If there are no significant automatic 
self-test failures, the command file should execute KUI to load _ the 
peripheral processor(s). 
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radial serial protocol (RSP), 
3-14 
TU58 DECtape II, 3-14 
Break-enable jumper 
SLU1, 3-39 
Breakpoints 
setting in multiple-processor 
systems, 3-42 
BRESET Signal, 1-8 
Building applications, 3-3 to 3-7 
See Application development and 
MPBLD utility 
Bus-master/Bus-Slave hardware 
concept, 1-1 


CCITT protocol, 3-28 
CFDKTC.MAC 
KXT11-C configuration file, D-1 
CFDKTC.MAC KXT11-C configuration 
file, 3-2 
Checksum 
creating with DECprom, 1-9 
specifying ROM test, 3-13 
Checksums 
calculating with DECprom, E-1 
CK clock device handler 
%INCLUDE file, 3-2 
prefix file, 3-2 
specifying to MPBLD, 3-6 
CKPFX.MAC prefix file, 3-2 
specifying to MPBLD, 3-6 
CLKLIB.PAS SINCLUDE file, 3-2 
Clock 
CSR and vector, B-l 
Clock (CK) device handler 
ZINCLUDE file, 3-2 
prefix file, 3-2 
specifying to MPBLD, 3-6 
CLOCK parameter 
KXTLIC macro, 1-8 
- CLOSE 
RT-11 programmed request, 4-2 
CLOSE command 
KUI program, 4-1 
@ command 
KUI program, 4-1 
Command register 
KW.DCO, A-3 
Communication protocol 
KK and KX device handlers, A-1l 
KK/KX device handlers, 1-8 
Configuration file 
CFDKTC.MAC, D-1 
installation verification, 3-2 
MicroPower/Pascal sample, D-1 
Configuration files 
CFDKTC.MAC, 3-2 
CONFIGURATION macro, D-1l 
Configuring KxT11-C hardware and 
software, 3-7 to 3-15 
Console ODT 
debugging setup, 2-5 
hardware setup, 3-15 
using, 2-5 
Console port 
use with debuggers, 2-5 
CPU test, 3-14 
CSR 
addresses for two-port RAM, C-1 
selection 
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avoiding conflicts, 2-7 
two-port RAM, 3-12 
CSR test, 3-14 
CTFCFS macro 
specifying when using DD 
handler, 3-31 


Data 
assuring DMA channel access, 
3-35 
local device transfers, 3-33 
local/local memory transfers, 
3-32 
local/Q-BUS memory transfers, 
3-32 
Q-BUS I/O page access, 3-35 
searching memory for, 3-33 
transferring variable-length 
messages, 3-33 
transferring with DTC, 3-31 to 
3=35 
use with SLU2, 3-34 
Data transfers 
using DMA transfer controller, 
1-1 
using two-port RAM, 1-1, 1-4 
DCT-11 microprocessor 
general description, 1-3 
DD device handler 
connecting to SLU2, 3-39 
features, 1-7 
prefix file, 3-2 
configuring, 3-31 
specifying to MPBLD, 3-6 
using, 3-39 
DDPFXK.MAC prefix file, 3-2 
configuring, 3-31 
specifying to MPBLD, 3-6 
Debugging 
building configuration, 2-4 
building RSX-11 arbiter system 
configuration, 4-5 
building RT-11 arbiter system 
configuration, 4-3 
console ODT hardware setup, 
3-15 
creating test process, 2-4 
hardware configuration, 2-5 to 
2-6 
integrated application, 2-5 
integrated application system, 
2-6 
KXT11-C applications, 3-39 to 
3-43 
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loading and starting target 
processors, 3-41 
loading application, 2-4 
MACDBG hardware setup, 2-5 
PASDBG 
general setup, 3-39 
PASDBG hardware setup, 2-5 
PASDBG with battery backup 
systems, 3-11 
ROM application, 2-4 
ROM configuration, 2-5 
RSX-11 arbiter 
KUI program, 4-5 
ODT program, 4-5 
RT-11 arbiter 
KUI program, 4-3 
ODT program, 4-3 
RT-11 or RSX-11 
arbiter-resident test 
program, 3-49 
setting boot/self-test switch, 
2-5 
setting system ID switch, 2-5 
setting TPR base address range 
_ jumper, 2-5 
size of DSM, 2-5 
special arbiter/KXT11-C 
locations, 3-42, 4-3, 4-5 
switching between multiple 
processors, 3-468, 3-41 
system hardware configuration, 
2-5 
system with battery backup, 
3-42 
test system setup, 3-39 
using console ODT, 2-5, 2-6 
using MACDBG, 2-4 
using MicroPower/Pascal 
arbiter-resident test 
program, 3-49 
using PASDBG, 2-4, 2-6 
DECprom, 1-7 
calculating ROM checksums, E-1l 
DECprom PROM loader, 1-9 
DECtape II 
See TU58 
Device handler 
asynchronous serial I/O (XL), 
3-27 
clock (CK) 
SINCLUDE file, 3-2 
prefix file, 3-2 
specifying to MPBLD, 3-6 
DMA transfer controller (QD) 
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assuring DMA channel access, 
3~-35 
INCLUDE file, 3-3 
local device transfers, 3-33 
local/local memory transfers, 
3-32 
local/Q-BUS memory transfers, 
3-32 
prefix file, 3-3 
specifying to MPBLD, 3-6 
Q-BUS I/O page access, 3-35 
search option, 3-33 
transferring variable-length 
messages, 3-33 
use in KXT11-C/arbiter, 3-36 
use with RSX-11 arbiter, 4-4 
use with RT-1l arbiter, 4-1 
use with SLU2, 3-34 
using, 3-31 to 3-35 
using with YK handler, 3-33 
DMA transfer controller (QD) 
interface routine 
library, 3-3 
DMA transfer controller (QD) 
interface routines, 3-31 - 
I/O packet definition file, 3-2 
interface routine 
SDMA TRANSFER, 3-31 
YK CLEAR TIMER, 3-16 
YK PORT READ, 3-16 
YK PORT WRITE, 3-16 
YK READ TIMER, 3-16 
YK_SET PATTERN, 3-16 
YK SET TIMER, 3-16 
interface routines, 3-1 
KX 
RT-11 limitations, C-l 
RT-11 vector allocation, C-l 
MicroPower/Pascal support 
routines, 1-8 
MicroPower/Pascal system files, 
3-1 
parallel I/O (YK) 
example counting pulses, 3-23 
example of analog I/0, 3-19 
example of D/A output, 3-21 
example of parallel output, 
3-17 
example of pulse generation, 
3-25 
INCLUDE file, 3-3 
performing DMA transfers, 
3-33 
prefix file, 3-3 
specifying to MPBLD, 3-6 
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using, 3-16 to 3-27 
parallel I/O (YK) interface 
routine 
library, 3-3 
parallel I/O (YK) interface 
routines, 3-16 
routines in RHSLIB.OBJ, 3-1 
specifying prefix files, 3-6 
synchronous serial line 
functions, 3-28 
specifying to MPBLD, 3-6 
synchronous serial line (XL) 
prefix file, 3-3 
synchronous serial line (XS 
functions, 3-28 
synchronous serial line (XS), 
3-28 to 3-39 
prefix file, 3-3 
specifying to MPBLD, 3-6 
source file, 3-3 
TU58 DECtape II (DD) 
connecting to SLU2, 3-39 
prefix file, 3-2 
configuring, 3-31 
specifying to MPBLD, 3-6 
using, 3-386 
two-port RAM (KK) 
ZINCLUDE file, 3-2 
prefix file, 3-2 
specifying to MPBLD, 3-6 
protocol 
See KK/KX protocol 
use in KXT11-C/arbiter 
interfacing, 3-36 
using, 3-35 
two-port RAM (KK) interface 
routine 
library, 3-3 
Two-port RAM (KX) 
RSX-11 unit numbers, 4-4 
two-port RAM (KX) 
logical units, 4-2 
prefix file, 3-2 
prefix file KKPFX.PAS, 3-35 
protocol 
See KK/KX protocol 
RSX-11 requests, 4-4 
RT-11 programmed requests, 
4-2 
RT-11 version features, 4-2 
specifying CSR, 3-12 
use in KXT11-C/arbiter 
interfacing, 3-36 
using, 3-35 
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two-port RAM (KX) interface 
routine 
library, 3-3 
two-port RAM interface routines 
INCLUDE file, 3-3 
Device handler interface 
SDMA ALLOCATE, 3-31 
SDMA DEALLOC, 3-31 
SDMA _GET STATUS, 3-31 
$DMA_SEARCH, 3-31 
KK READ DATA, 3-35 
KK WRITE DATA, 3-35 
Device handlers 
arbiter processor, 1-2 
description, 3-15 to 3-35 
KXT11-C, 1-2 
asynchronous serial line (XL), 
1-7 
DMA transfer controller (QD), 
1-8 
parallel I/O (YK), 1-8 
synchronous serial line (XS), 
1-7 
TU58 DECtape II (DD), 1-7 
two-port RAM handler (KK), 


routine 


1-8 
two-port RAM (arbiter) handler 
(KX), 1-8 
two-port RAM (KX), 1-9 
DEVICES macro, 3-5, D-1 
Diagnostic tests 
See Tests 
DLART 
SLU1 and SLU2 channel B support, 
3-27 
DLV11-E 
SLU2 support, 3-27 
DMA 


use by YK device handler, 1-8 
use with SLU2, 3-34 
DMA test, 3-14 
DMA transfer controller 
assuring DMA channel access, 
3-35 
criteria for using, 2-3 
CSR and vector, B-l 
general description, 1-4 
local device transfers, 3-33 
local/local memory transfers, 
3-32 
local/Q-BUS memory transfers, 
3-32 
Q-BUS I/O page access, 3-35 
search option, 3-33 


transferring variable-length 
messages, 3-33 
use with RSX-11 arbiter, 
use with RT-11 arbiter, 
use with SLU2, 3-34 
using, 3-31 to 3-35 
DMA transfer controller (QD) 
use in KXT11-C/arbiter 
interfacing, 3-36 
using with YK handler, 3-33 
DMA transfer controller (QD) 
device handler, 1-8 
%INCLUDE file, 3-3 
interface routine library, 
interface routines, 3-31 
prefix file, 3-3 
specifying to MPBLD, 3-6 
use with RSX-11l arbiter, 4-4 
use with RT-1l1 arbiter, 4-1 
SDMA ALLOCATE 
device handler interface 
routine, 3-31 
DMA ALLOCATE command, 
SDMA DEALLOC 
device handler interface 
routine, 3-31 
SDMA GET STATUS 
device handler interface 
routine, 3-31 


4-4 
4-1 


3-3 


3-35 


_$DMA_SEARCH 


device handler interface 
routine, 3-31 


‘$DMA_TRANSFER 


device handler interface 
routine, 3-31 
DRV.OBJ library file, 
DRVK. OBJ 
library 
DD handler, 3-31 
DRVK.OBJ library, 3-2, 
DRVM.OBJ library, 3-2, 
DRVU.OBJ library, 3-2, 
DTC 
See DMA transfer controller 


321 


3-35 
3-35 
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Error 
ISO HDLC detection, 
Brrors 
automatic self-—tests 
reporting, 3-15 
detecting KXT11-C during 
loading, 4-3, 4-6 
KXT11-C 
fatal, 


3-23 


3-13 
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program detection of firmware, 
F-~1 
self-tests 
reporting, 3-13 
- EXE file type 
use with DECprom, 1-9 
EXECUTE command 
KUI program, 
EXIT command 
KUI program, 


4-2 
4-2 


FB RT-11 monitor, 4-3 
FCS 
See Frame checker sequence 
File system 
MicroPower/Pascal, 
File types 
loaded by KUI program, 4-3, 
Files 
$INCLUDE for application 
building, 3-1 
MicroPower/Pascal 
device handler, 3-1 
prefix, 3-1 
MicroPower/Pascal software for 
KXT11-C, 3-1 
Firmware 
See Native firmware 
Frame checker sequence 
XS device handler, 3-28 
Framing 
ISO HDLC, 


i at A 
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GO command 
PASDBG, 3-49 
GO/EXIT command 

PASDBG, 3-41, 
GO/INIT command 
PASDBG, 3-42 
GREGS$ RSX-11 directive, 


3-42 


4-4 


Handlers 
See Device handlers 
Hardware 
configuration guidelines, 3-7 
to 3-15 
debugging configuration, 2-5 to 
2-6 
final application configuration, 
2-7 
jumper 
battery backup, 3-19 
map selection, 3-9 
memory map, 3-15 
memory map selection, 3-39 


SLU1 baud, 3-39 
SLU1 break-enable, 3-39 
TPR base address, 3-12 
selecting memory map, 2-7 
selecting memory map for 
debugging, 2-5 
system configuration for 
debugging, 2-5 
test system setup, 3-39 
Hardware configuration 
peripheral processor, 1-6 


I/O 
configuration and programming, 
3-15 
I/O definitions INCLUDE file 
IODEF.PAS, 3-2 
I/O devices 
configuration and programming, 


3-35 

I/O packet 

SINCLUDE file, 3-1, 3-2 
I/O page 

arbiter 

selecting two-port RAM base 
address, 3-12 
arbiter TPR area, 1-6 


avoiding CSR assignment 
conflicts, 2-7 
setting arbiter TPR base 
address, 2-5 
two-port RAM registers, 1-1 
I/O ports 
configuring, 2-5 
IBM SDLC protocol, 
INCLUDE 
device handler interface 
routine, 3-35 
files for KXT11-C application 
building, 3-1 
INIT/RESTART command 
PASDBG, 3-43 
Initialization options 
selecting, 3-12 
Installation verification 
configuration file, 3-2 
Installation/Verification 
command file, 3-3 
Installation/verification 
(arbiter) programs 
source files, 3-3 
Installation/verification 
(KXT11-C) programs 
source files, 3-3 
Interface 


3-28 
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KK/KX example, 3-37 KC.IDR bit, A-4 
Interface considerations, 3-38 KK/KX protocol, A-9, A-11l 
Interface design considerations, KC.LEN field 
3-36 KK/KX protocol, A-196, A-11 
Interface routines KC.VEC field 
See Device handler KK/KX protocol, A-9, A-1ll 
Interrupt vector KESILC code 
See Vector KK/KX protocol, A-12 
IO.ATT KESILL code 
RSX-11 KX handler request, 4-4 KK/KX protocol, A-12 
IO.DET KESILV code 
RSX-11 KX handler request, 4-4 KK/KX protocol, A-12 
IO. RVB KESNDA code 
RSX-11 KX handler request, 4-4 KK/KX protocol, A-12 
IO.WVB KESNDR code 
RSX-11 KX handler request, 4-4 KK/KX protocol, A-12 
IODEF.PAS %$INCLUDE file, 3-2 KESOK code 
IOPKTS.PAS %INCLUDE file, 3-2 KK/KX protocol, A-12 
IOPVFY.PAS file, 3-3, 3-37 KESOVR code 
ISO HDLC framing and error KK/KX protocol, A-12 
detection, 3-28 Kernel 
ISO HDLC protocol, 3-28 features controlled by KXT11C 
macro, 1-8 
Jumper optimizing, 3-4 
battery backup, 3-194 restart after power failure, 
map selection, 3-9 3-11 
memory map, 3-15 KK device handler, 1-8 
memory map selection, 3-39. communication protocol, 1-8 
SLU1 baud, 3-39 interface routine 
SLU1 break-enable, 3-39 library, 3-3 
TPR base address, 3-12 interface routines 
TPR base address range, 2-5 - $INCLUDE file, 3-3 
prefix file, 3-2 
KCSDI command specifying to MPBLD, 3-6 
KK/KX protocol, A-9 protocol 
KCSEI command See KK/KX protocol 
KK/KX protocol, A-9 special arbiter/KXT11-C 
KCSGS command debugging locations, 3-42, 
KK/KX protocol, A-9 4-3, 4-5 
KCSNOP command use in KXT11-C/arbiter 
KK/KX protocol, A-8 interfacing, 3-36 
KCSRD command using, 3-35 
KK/KX protocol, A-1@ KK two-port RAM device handler 
KCSRSM command INCLUDE file, 3-2 
KK/KX protocol, A-9 KK/KX protocol, A-1 to A-13 
KCSSS command command register definitions, 
KK/KX protocol, A-9 A-8 to A-11 
KCSWD command concepts, A-3 
KK/KX protocol, A-1@ interface initialization, A-13 
KC.COM command field interrupting when data is 
KK/KX protocol, A-8 available, A-7 
KC.EOM bit interrupting when data is 
KK/KX protocol, A-19, A-11 requested, A-7 
KC.IDA bit, A-4 KCSDI command, A-9 
KK/KX protocol, A-9, A-11 KCSEI command, A-9 
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KCSGS command, A-9 

KCSRD command, A-190 

KCSRSM command, A-9 

KCSSS command, A-9 

KCSWD command, A-19 

KC.COM command, A~8 

KC.COM command field, A-8 

KC.EOM bit, A-19, A-11 

KC.IDA bit, A-9, A-11 

KC.IDA command register bit, 
A-4 

KC.IDR bit, A-9, A~11 

KC.IDR command register bit, 
A-4 

KC.LEN field, A-16, A-11 

KC.VEC field, A-9, A-1ll 

KESILC code, A-12 

KESILL code, A-12 

KESILV code, A-12 

KESNDA code, A-12 

KESNDR code, A-12 

KESOK code, A~12 

KESOVR code, A-12 

KS.ALN field, A-13 

KS.DA bit, A-13 

KS.DA status register bit, A-4 

KS.DR bit, A-12 

KS.EOM bit, A-12 

KS.ERC field, A-12 

KS.ERR bit, A-13 

KS.IEN bit, A-13 

KS.ON bit, A-13 

KW.DCO register, A-3 

-master/slave relationship, A-1 

message communication, A-§ 

register definitions, A-8 to 
A-13 

status register definitions, 
A-1l1 to A-13 

synchronizing KK and KX handler 
operation, A-7 


KK READ DATA 


device handler interface 
routine, 3-35 


KK WRITE DATA 


device handler interface 
routine, 3-35 


KK/KX protocol, A-13 
KS.DA status register bit, A-4 
KS.DR bit 
KK/KX protocol, A-12 
KS.EOM bit 
KK/KX protocol, A~-12 
KS.ERC field 
KK/KX protocol, A-12 
KS.ERR bit 
KK/KX protocol, A-13 
KS.IEN bit 
KK/KX protocol, A-13 
KS.ON bit 
KK/KX protocol, A-13 
KSLU2 kernel module, B-2 
KT LOAD procedure 
SINCLUDE file, 3-3 
KUI load utility 
description, 1-9 
KUI program 
commands, 4-1 
debugging RSX-11 arbiter 
applications, 4-5 
debugging RT-11 arbiter 
applications, 4-3 
features, 4-1 
loading debugging configuration, 
2-4 
loading final application, 2-7 
loading final RT-11 arbiter 
application, 4-3 
loading KXT11-C from RSX-11 
arbiter, 4-5 
TPR system control register use, 
A-3 
use with PASDBG, 3-41 
using, 3-14 
KX device handler, 1-8, 1-9 
communication protocol, 1-8 
interface routine 
library, 3-3 
logical unit IDs, C-1l 
logical units, 4-2 
prefix file, 3-2 
prefix file KKPFX.PAS, 3-35 
protocol 
See KK/KX protocol 


KKINC. PAS 
ZINCLUDE file, 3-35 
KKINC.PAS %INCLUDE file, 3-2, 3-3 
KKPFXK.MAC prefix file, 3-2 
specifying to MPBLD, 3-6 
KS.ALN field 
KK/KX protocol, A-13 
“KS.DA bit 


RSX-11 requests, 4-4 

RSX-11 unit numbers, 4-4 

RT-11 limitations, C-l 

RT-11 programmed requests, 4-2 
RT-11 vector allocation, C-l 
RT-~11 version features, 4-2 
specifying CSR, 3-12 
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use in KXT11-C/arbiter 
interfacing, 3-36 
using, 3-35 
KXLINC.PAS %INCLUDE file, 3-3 
KXPFX.MAC prefix file, 3-2 
KXTSRI recovery indicator, 3-11 
KXT11-C 
configuring hardware, 3-7 to 
3-15 
configuring system environment, 
3-11 to 3-15 
CSR and vector assignments, B-l 


to B-3 
DCT-11 microprocessor features, 
1-3 
debugging 
loading and starting target, 
3-41 


device handlers 
See Device handlers 
fatal error, 3-13 
hardware features, 1-2 
jumper 
battery backup, 3-19 
memory map selection, 3-39 
SLU1 baud, 3-39 . 
SLU1 break-enable, 3-39 
TPR base address, 3-12 
loading from arbiter, 3-14 
memory 
general description, 1-3 
loading with KUI utility, 1-9 
loading with KXT LOAD, 1-9 
memory configuration steps, 3-8 
memory map usage by 
MicroPower/Pascal, 3-19 
MicroPower/Pascal system files, 
3-1 
native firmware 
features, 1-3 
peripheral processor 
See Peripheral processor 
peripheral processors 
Q-BUS limits, 3-12 
Programming languages, 1-2 
programming languages, 1-1 
programming with 
MicroPower/Pascal, 3-1 to 
3-43 
QIR register, A-1 
RT-11 arbiter 
supporting additional 
peripheral processors, 
4-2 
stand-alone operation 


See Stand-alone operation, 
1-1 
switches 
system ID, 3-12 
use aS a peripheral processor, 
1-9 
use as peripheral processor, 
1-4 
KXT11-C hardware 
debugging configuration, 2-5 
KXT11-C macro 
POWER parameter, 3-11 
KXT11C macro, 3-5, D-1l 
kernel control parameters, 1-8 
KXT LOAD procedure 
description, 1-9 
library, 3-3 
loading debugging configuration, 
2-4 
loading final application, 2-7 
TPR system control register use, 
A-3 
use with PASDBG, 
KXT LOAD routine 
loading KXT11-C, 3-14 
KXTCSRA register, B-l 
KXTDF$ macro, 4-3, 4-4 
SKXTOR 
arbiter/KXT11-C debugging 
location, 3-42, 4-3, 4-5 
SKXTOQW 
arbiter/KXT11-C debugging 
location, 3-42, 4-3, 4-5 


3-41 


-LDA file type 
loading with KUI program, 4-3 
use with DECprom, 1-9, E-1l 
LED display, 3-15 
fatal errors, 3-13 


Library 
device handler interface 
routine 
RHSLIB.OBJ, 3-35 
DRVK. OBJ 


DD handler, 3-31 

KXT11-C device handler 
DRVK.OBJ, 3-2, 3-35 
DRVM.OBJ, 3-35 
DRVU.OBJ, 3-35 

mapped arbiter device handler 
DRVM.OBJ, 3-2 

unmapped arbiter device handler 
DRVU.OBJ, 3-2 

Library file 
DRV.OBJ, 3-1 
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LINDF$ macro, 3-27 
LINK, 1-7 
LOAD command 
KUI program, 4-2, 4-3, 
PASDBG, 3-48, 3-41, 
LOAD/SYM command, 3-42 
PASDBG, 3-42 
Loading 
application configured for 
debugging, 2-4 
final RSX-11 arbiter 
application, 4-5 . 
final RT-11 arbiter application, 
4-3 
integrated application, 2-7 
KXT11-C 
from arbiter, 3-14 
from RT-11 and RSX-11 systems, 
3-14 
KXT LOAD routine, 3-14 
TU58 DECtape II, 3-14 
KXT11-C from arbiter, 2-7 
KXT11-C from TU58 DECtape II, 
4-3, 4-5 
LOG command 
KUI program, 4-1 
Logical unit IDs 
KX device handler, C-l 
Logical units 
KX device handler, 
Loopback tests, 3-15 
selecting, 2-5 
LSI-11 
arbiter processor, 
LSI-ll systems 
adding peripheral processors, 
1-5 


4-6 
3-43 


4-2 


1~] 


MACDBG, 1-7 

debugging application, 2-4 

hardware setup, 2-5 

Size of DSM, 2-5 
MACRO~11 

progamming language, 1-2 
MACRO-11 assembler, 3-4 
Macros 

configuration file, D-1 
Map 

See Memory map 
MAP parameter 

KXT11C macro, 
Master protocol, 
Master/slave 

software architecture, 1-1 


LS 
3-35 


Master/Sslave architecture, 
1-8 


1-6 r) 


- Master/Slave relationship 


KK/KX protocol, A-1l 
Memory 
address conversion function 
RT-11 KX handler, 4-3 
addresses 
calculating physical, 3-38 
assuring DMA channel access, 
3-35 
configuration 
loading from TU58 DECtape II, 
3-9 
native firmware restrictions, 
3-9 
determining program storage 
requirements, 3-4 
KXT11-C 
configuration steps, 3-8 
general description, 1-3 
selecting maps, 3-7 
loading KXT11-C with KUI 
utility, 1-9 
loading KXT11-C with KxXT_LOAD, 
1-9 
local device transfers, 3-33 
local/local transfers, 3-32 
local/Q-BUS transfers, 3-32 
map jumper, 3-15 
map layout, 3-8 
map selection jumper, 3-9 
map selection rules, 3-9 
maps used by MicroPower/Pascal, 
3-19 
Q-BUS I/O page access, 
RSX-11 arbiter 
accessing shared memory areas, 
4-4 
calculating physical 
addresses, 4-4 
protecting shared data areas, 
4-5 
RT-11 arbiter 
calculating physical 
addresses, 4-3 
search option, 3-33 . 
selecting map for debugging, 
2-5 
selecting map for final 
configuration, 2-7 
specifying in MEMORY macro, 3-9 
specifying maps, 3-5 
transferring data with DTC, 
3-31 to 3-35 


3-35 
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transferring variable-length 


messages, 3-33 
use with SLU2, 3-34 
MEMORY macro, D-1 


specifying maps, 3-5 
specifying memory blocks, 3-9 
Memory map jumper, 3-15 
battery backup, 3-198 
selection, 3-39 
TPR base address, 3-12 
Memory map selection jumper, 3-9 
MERGE 
creating debugging 
configuration, 
Message 
passing, 2-3 
Message passing 
See Data transfers 
MIB 
creating debugging 
configuration, 
MIB program, 3-4 
use in determining 
requirements, 
MicroPower/Pascal 
application building 
KXT11-C differences, 3-1 
arbiter 
debugging with test program, 
3-48 
building optimized kernel, 3-4 
device handlers, 1-2 
features, 1-2, 1-7 
kernel 
restart after power failure, 
3-11 , 
memory restrictions for KXT11-C, 
3-9 
operating environment, 1-1 
programming KXT11-C, 3-1 to 
3-43 
programming language, 1-2 
programming languages, 2-2 
sample KXT11-C configuration 


2-4 


2-4 


memory 
3-4 


file, D-1 
system files for KXT11-C, 3-1 
MicroPower/Pascal compiler, 3-4 


MicroPower/Pascal Software 
configuration guidelines, 3-7 
MicroPower/Pascal software 
configuration guidelines, 3-15 
-MIM file type 
loading with KUI program, 4-3, 
4-5 


use with DECprom, 1-9, E-1l 


-MIM files 
building peripheral processing 
applications, 3-1 
peripheral processing 
application building, 3-1 
MPBLD utility 
building applications, 
3~7 
building KxXT11-C applications, 
3-1 
Multiple processors 
switching PASDBG between, 
Multiprotocol controller 
See also XS device handler 
XL handler, 3-27 


3-3 to 


3-Al 


Native firmware 
error conditions 
program detection of, 
features, 1-3 
initialization after power 
failure, 3-11 
memory configuration 
restrictions, 3-9 
selecting options, 3-12 


F-1 


ODT 
See Console ODT 
ODT command 
KUI program, 
ODT program 
RSX-11 arbiter debugging, 4-5 
RT-11 arbiter debugging, 4-3 


4-2, 4-3, 4-5 


'. OPEN 


RT-11 programmed request, 4-2 
OPTIMIZE 


SYSTEM macro parameter, 3-4 


Packet 
See I/O packet 
Parallel I/0 
CSR and vector, B-3 
Parallel I/O (YK) device handler, 
1-8 
DMA feature, 1-8 
example counting pulses, 3-23 
example of analog I/0, 3-19 
example of D/A output, 3-21 
example of parallel output, 
3-17 
example of pulse generation, 
3-25 
ZINCLUDE file, 3-3 
interface routine library, 
interface routines, 3-16 


a3 


Index-1ll 


INDEX 


performing DMA transfers, 3-33 
prefix file, 3-3 
specifying to MPBLD, 
using, 3-16 to 3-27 
Parallel processing, 2-1 
Partitioning an application, 2-1 
PASDBG 
/AFTER modifier, 3-42 
building into application, 2-4 
debugging 
ROM systems, 3-8 
systems with battery backup, 
3-11 
debugging integrated 
application, 2-6 
general setup for debugging, 
3-39 
GO command, 3-46 
GO/EXIT command, 3-41, 
GO/INIT command, 3-42 
hardware setup, 2-5 
INIT/RESTART command, 3-43 
LOAD command, 3-494, 3-41, 
LOAD/SYM command, 3-42 
/PROCESS modifier, 3-42 
setup as single host process, 
3-41 
SHOW TARGET command, 3-42 
size of DSM, 2-5 
Switching between multiple 
processors, 3-49, 3-41 
PB-11 PROM loading system, 1-9 
Peripheral processing 
debugging 
setting breakpoints and 
watchpoints, 3-42 
Peripheral processor 
adding to traditional LSI-11 
systems, 1-5 
application development 
MicroPower/Pascal, 1-1 
RT-11 and RSX tool kits, 1-1 
RT~11 and RSX-11 tool kits, 
1-2, 1-9 ; 
application development . 
procedures, 2-1 to 2-7 
application software 
configuration, 1-6, 
applications 
partitioning, 2-1 
communication with arbiter, 
1-9 
debugging configuration, 
environment, 1-1 
hardware configuration, 1-6 


3-6 


3-42 


3-43 


1-7 


1-6 , 


2-5 


hardware setup, 3-12 
interface considerations, 
KK/KX example, 3-37 
interface design considerations, 
3-36 
loading 
KUI utility, 1-9 
KXT_LOAD procedure, 1-9 
master/Slave architecture, 1-6 
-MIM files required, 3-1 
relationship with arbiter 
processor, 1-1 
RT-11 arbiter 
Supporting five or more 
peripheral processors, 
4-2 
software architecture, 1-l 
typical applications, 1-4 
Peripheral processor application 
development, 3-1 
Power failure 
recovery after, 3-19, 
POWER parameter 
.KXT11-C macro, 
KXT11C macro, 
Power-up 
selecting type of, 2-5 
tests 
Selecting, 2-5 
PPVFY verification procedure, 
3-41 
PPVFY.CMD file, 3-3 
PPVFY.COM file, 3-3 
Prefix file 
specifying to MPBLD, 
Primitives 
MicroPower/Pascal kernel 
optimization, 3-4 
PRIMITIVES macro, 3-4, D-l 
/PROCESS modifier 
PASDBG, 3-42 
PROCESSOR macro, 3-5, 
Programming languages 
KXT11-C, 1-1, 1-2 
PROM/RT-11, 1-7 


3-38 


3-11 


S-12 
1-8 


3-6 


D-1 


PROM/RT~11 PROM loader, 1-9 
Protocol 

master, 3-35 

Slave, 3-35 
Q-BUS 

KXT11-C limitations, 3-12 


Q-BUS interrupt 
CSR and vector, 
QD device handler, 


B-2 
1-8 


Index-12 


INDEX 


assuring DMA channel access, 


3~35 
calculating physical addresses 
for, 3-38 


interface routine 
library, 3-3 
interface routine $INCLUDE file, 
3-3 
interface routines, 3-31 
local device transfers, 3-33 
local/local memory transfers, 
3-32 
local/Q-BUS memory transfers, 
3-32 
prefix file, 3-3 
specifying to MPBLD, 3-6 
Q-BUS I/O page access, 3-35 
search option, 3-33 
transferring variable-length 
messages, 3-33 
in KXT11-C/arbiter 
interfacing, 3-36 
with RSX-l1l arbiter, 4-4 
use with RT-11 arbiter, 4-1 
use with SLU2, 3-34 
using, 3-31 to 3-35 
using with YK handler, 3-33 
QDINC.PAS $INCLUDE file, 3-3 
QDPFXK.MAC prefix file, 3-3 
specifying to MPBLD, 3-6 
QIR 
CSR, B-2 
QIR register, A-1 


use 


use 


Radial serial protocol (RSP) 
bootstrap loader, 3-14 
RAM 
battery backup vector, B-3 
determining program storage 
requirements, 3-4 
rules for selecting, 3-9 
selecting battery backup, 3-19 
selecting maps for, 3-7 
specifying base address, 3-6 
use in place of ROM when 
debugging, 3-8 
RAM test, 3-14 
- READ 
RT-11 programmed request, 4-2 
Read-only memory 
See ROM 
. READC 
RT-11 programmed request, 
- READW 
-RT-11 programmed request, 


4-2 


4-2 


Recovery 


after power failure, 3-11 


Recovery indicator KXTSRI, 3-11 
Register definitions 

Two-port RAM, A-8 

two-port RAM, A-8 to A-13 
REINIT command 

KUI program, 4-2, 4-3, 4-6 


RELOC 
creating debugging 
configuration, 2-4 
RELOC program, 3-4 
use in determining memory 
requirements, 3-4 
RESET parameter 
KXT11C macro, 1-8 
RESET vector, B-3 
RESOURCES macro, 
RESUME command 
KUI program, 
RHSLIB.OBJ 
library, 3-35 
RHSLIB.OBJ library, 3-3 
device handler interface 
routines, 3-1 


D-1 
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ROM 
application debugging, 2-4 
application start-up 
selecting, 3-13 
calculating checksums for, E-1l 
debugging configuration, 2-5 
debugging considerations, 3-8 
determining program storage 
requirements, 3-4 
loading with DECprom and 
PROM/RT-11, 1-9 
selecting maps for, 3-7 
selecting power-up tests, 
specifying checksum test, 
ROM rules for selecting, 3-9 
ROM test, 3-14 
RSX 
operating environment, 1-1 
RSX-11 
arbiter 
accessing shared memory areas, 
4-4 
building system debugging 
configuration, 4-5 
final configuration, 4-5 
KUI program, 4-5 
KX handler requests, 4-4 
loading final application, 
4-5 


2-5 
3-13 


Index-13 


INDEX 


protecting shared data areas, 
4-5 
using test program, 3-49 
arbiter application development, 
4-6 
GREGS directive, 4-4 
programming language, 2-2 
RSX-11 arbiter application 
development, 4-4 
RSX-11M 
See RSX 
RSX-11M-PLUS 
See RSX 
RT-11 
arbiter 
building system debugging 
configuration, 4-3 
final configuration, 4-3 
KUI pDrogram, 4-3 
loading final application, 
4-3 
programmed requests for KX 
handler, 4-2 
supporting five or more 
peripheral processors, 
4-2 
using test program, 3-48 
KX device handler logical unit 
limitations, C-l 
KX device handler vector 
allocation, C-1 
operating environment, 1-1 
programming language, 2-2 
RT-11 arbiter application 
development, 4-2 to 4-3 


-SAV file type 
loading with KUI program, 4-3 
use with DECprom, 1-9, E-1l 
Search option 
QD handler, 
Self-test 
KUI command to execute, 
selecting, 3-12 
selecting for ROM applications, 
3-13 
Self-—tests 
automatic, 3-14 
detecting error conditions, 
F-1l 
error reporting, 3-13 
selecting, 2-5 
SELFTEST command. 
KUI program, 4-2 
SET command 


3-33 
4-2 


KUI program, 4-1 
SHOW command 
KUI program, 4-1 
SHOW TARGET command 
PASDBG, 3-42 
SJ RT-11 monitor, 4-3 
Slave protocol, 3-35 
Slave/Master relationship 
KK/KX protocol, A-l 
SLU1 
CSR and vector, B-1l 
DLART support, 3-27 
loading programs from TU58 
DECtape II, 3-14 
specifying prefix file to MPBLD, 
3-§ 
SLU2 
connecting TU58 DECtape II, 
3-39 : 
DLART Support, 3-27 
DMA access, 3-33 
hardware CSR and vector, B-l 
software CSR and vector, B-2 
specifying prefix file to MPBLD, 
3-6 
using with DMA, 3-34 
vector fan-out module, 
~ SPFUN 
KX handler function, 
Stand-alone operation 
general requirements, 
Stand-alone processor 
application development 
procedures, 2-7 
hardware setup, 3-12 
Starting 
ROM application, 3-13 
SUSPEND command 
KUI program, 
Switch 
system ID, 3-12 
Synchronous serial 
device handler 
prefix file, 3-3 
Synchronous serial 
device handler 
prefix file 
specifying to MPBLD, 3-6 
Synchronous serial line (XS) 
- device handler, 1-7 
prefix file, 3-3 
specifying to MPBLD, 3-6 
source file, 3-3 
using, 3-28 to 3-30 
System control registers 


B-2 
4-3 


1-9 


4-1 


line (XL) 


line (XL) 


Index-14 


two-port RAM (KX) 
using, 3-14 
use by KUI program, A-3 
use by KXT LOAD procedure, A-3 
System ID switch, 2-5 


INDEX 


associated two-port RAM CSR and 


vector assignments, C-1 
selecting, 3-12 
use, 3-12 


Target processor 
debugging 
loading and starting, 3-41 
Target processors 
loading and starting, 3-12 
Test 
CPU, 
CSR, 
DMA, 
RAM, 
ROM, 
Testing 
integrated application system, 
2-6 
KXT11-C applications, 2-3 
Tests 
See also Power-up self-tests 


3-14 
3-14 
3-14 
3-14 
3-14 


automatic self-tests, 3-14 
dedicated off-line, 3-15 
developing, 2-4 
loopback, 3-15 
obtaining status information, 
3-14 
8254 timer 
CSR and vector, B-1l 
TKB, 1-7 
Tool kits 
See Application development 
tools 


Tool kits for RT-11 and RSX-11 
arbiter applications, 4-1, 
4-6 
Tools . 
See Application development 
tools 
TPR 
See Two-port RAM 
TRAP command 
KUI program, 4-2, 
TRAPS macro, D-1 
-TSK file type 
loading with KUI program, 
use with DECprom, 1-9 
TU58 DECtape II 
bootstrap loader, 


4-3, 4-5 
4-5 


3-14 


loading debugging configuration, 
2-4 

loading final application, 

loading KXT11-C, 4-3, 4-5 

memory configuration 
requirement, 3-9 


2-7 


TU58 DECtape II (DD) device 


handler, 1-7 


TU58 DECtape II device handler 


connecting to SLU2, 
prefix file, 3-2 
configuring, 3-31 
specifying to MPBLD, 
using, 3-39 


3-39 
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Two-port RAM 


-KESILC 


command register, A-1l 

command register definitions, 
A-8 to A-l1l 

criteria for using, 2-3 

CSR and vector, B-2 

CSR and vector assignments, 

data channel, A-1l 

data registers, A-l 

disabling, 3-12 

enabling, 3-12 

KCSDI command, A-9 

KCSEI command, A-9 

KCSGS command, A-9 

KCSNOP command, A-8 

KCSRD command, A-186 

KCSRSM command, A-9 

KC$SS command, A-9 

KCSWD command, A-194 

KC.COM command field, A-8 

KC.EOM bit, A-19, A-11 

KC.IDA bit, A-9, A-ll 

KC.IDR bit, A-9, A-11 

KC.LEN field, A-19, A-11 

KC.VEC field, A-9, A-11 

code, A-12 

code, A-12 

code, A-12 

KESNDA code, A-12 

KESNDR code, A-12 

KESOK code, A-12 

KESOVR code, A-12 

KS.ALN field, A-13 

KS.DA bit, A-13 

KS.DR bit, A-12 

KS.EOM bit, A-12 

KS.ERC field, A-12 

KS.ERR bit, A-13 

KS.IEN bit, A-13 

KS.ON bit, A-13 

master/slave architecture, 


C-1 


KESILL 
KESILV 


1-1 


Index-15 


message passing, 1-4 
register definitions, A-8 to 
A-13 
registers in I/O page, 1-1 
selecting base address, 3-12 
status register definitions, 
A-11 to A-13 
system control registers, 3-14 
use, 1-3 
Two-port RAM (arbiter) device 
handler (KX), 1-8 
Two-port RAM (KK) device handler 
ZINCLUDE file, 3-2 
interface routine 
library, 3-3 
prefix file, 3-2 
specifying to MPBLD, 3-6 
protocol 
See KK/KX protocol 
use in KXT11-C/arbiter 
interfacing, 3-36 
using, 3-35 
Two-port RAM (KX) device handler 
interface routine library, 3-3 
prefix file, 3-2 
prefix file KKPFX.PAS, 3-35 
protocol. 
See KK/KX protocol 
RSX-1l1 requests, 4-4 
RSX-11 unit numbers, 4-4 
RT-11 programmed requests, 4-2 
RT-11 version features, 4-2 
specifying CSR, 3-12 
use in KXT11-C/arbiter 
interfacing, 3-36 
using, 3-35 
Two-port RAM (KXT11-C) device 
handler (KK), 1-8 
Two-port RAM device handler, 1-9 
TYPRM parameter 
specifying when using DD 
handler, 3-31 


Unit numbers 
KX handler 
RSX-11l arbiter, 4-4 
RT-11 arbiter, 4-2 
User sockets 
specifying ROM and RAM, 3-9 


Vector 
assignments for two-port RAM, 
C-1 
Kernel power-up, 3-ll 
selection 


INDEX 


avoiding conflicts, 2-7 

Vector 129 

KXT11-C, A-3 
Vector 124 

KXT11-C, A-3 
Vectors 

KXT11-C assignments, B-l to B-3 
Verification procedures 

PPVFY, 3-41 


Watchpoints 

setting in multiple-processor 

systems, 3-42 

e-WRITC 

RT-11 programmed request, 4-2 
-WRITE 
'RT-11 programmed request, 4-2 
~WRITW 

RT-11 programmed request, 4-2 


X.25 protocol, 3-28 
XL device handler 
features, 1-7 
prefix file, 3-3 
specifying to MPBLD, 3-6 
using, 3-27 
XLPFXK.MAC prefix file, 3-3 
specifying to MPBLD, 3-6 
XM RT-11 monitor, 4-3 
XS device handler, 1-7 
configuration, 3-29 
functions, 3-28 
prefix file, 3-3 . 
specifying to MPBLD, 3-6 
source file, 3-3 
using, 3-28 
XSINT.MAC file, 3-3 
XSPFXK.MAC prefix file, 3-3 
specifying to MPBLD, 3-6 


YK device handler, 1-8 
DMA feature, 1-8 
example counting pulses, 3-23 
example of analog I/O, 3-19 
example of D/A output, 3-21 
example of parallel output, 
3-17 

example of pulse generation, 

— 3-25 
interface routine 

library, 3-3 
interface routines, 3-16 
performing DMA transfers, 3-33 
prefix file, 3-3 

specifying to MPBLD, 3-6 
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using, 3-16 to 3-27 
YK parallel I/0 device handler 
INCLUDE file, 3-3 
YK CLEAR TIMER 
device handler interface 
routine, 3-16 
YK_PORT READ 
device handler interface 
routine, 3-16 
YK PORT WRITE 
device handler interface 
routine, 3-16 


INDEX 


YK READ TIMER 
device handler interface 
routine, 3-16 
YK SET PATTERN 
device handler interface 
routine, 3-16 
YK SET TIMER 
device handler interface 
routine, 3-16 
YKINC.PAS %INCLUDE file, 3-3 
YKPFXK.MAC prefix file, 3-3 
specifying to MPBLD, 3-6 
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